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ABSTRACT 


This thesis explores the Bahrain Defense Force (BDF) needs for a decision 
support system in the area of analyzing, establishing and maintaining the organizational 
structures of BDF units. It also identifies the BDF measures that must be taken to qualify 
a certain unit structure. 

Subsequently, the thesis designs and develops a specific DSS prototype that can 
aid BDF decision makers and planners perspectives in this area. Creating this prototype 
has involved three different layers to be investigated; the data, the models and the user 
interfaces. The data layer consists of a Microsoft Access™ database application that 
houses BDF Units, Manpower, Vehicles, Weapons, Salaries, and Jobs information. The 
model layer consists of two Microsoft Excel™ spreadsheets that contain Infantry 
Battalion and enhanced Armor Battalion HR optimization models. The UI layer consists 
of user controls, input/output forms, queries, reports, and visualization aids (i.e. charts 
and pivot tables). These interfaces were developed using MS Access capabilities. 
Consequently, the BDF DSS is an integration of database and optimization technology 
using widely available desktop tools. 

The general benefits of this DSS are reduced costs for data gathering, 
computation, and data presentation, and added value resulting from investigating more 
alternatives, doing more sophisticated analyses of alternatives, using better methods of 
comparing alternatives, and making quicker and better decisions. 
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I. INTRODUCTION 


A. BACKGROUND 

Given the eomplexity of military organizational struetures and the need to 
establish modernized military forees, BDF deeision makers or planners require database 
teehnology to support the proeesses of analyzing, establishing and maintaining different 
kinds of BDF organizational struetures. For instanee, during the study phase, and before 
approving a proposed BDF unit organizational strueture, BDF-HQ needs to know the 
estimated fixed eost and the running eost in establishing and maintaining sueh a unit. 
Also, BDF-HQ needs to eompare all eost drivers of a proposed unit to other existing units 
whieh would generate more choiees for BDF-HQ deeision-makers. 

Currently, the BDF eurrent system of doing such processes is done manually and 
indeed there are many associated anomalies to that system which sometimes impair the 
growth of BDF in different aspects. Consequently, and as an illustration of the required 
decision support tool, this research involves building and prototyping a database and 
associated decision model to support the following BDF requirements: 

1. To build an organizational structure and establishment satisfying manpower and 
operational equipment requirements (vehicles and weapons) of an organization. 

2. To track and highlight the vacancies and requirements of the new and existing 
organization. 

3. To compute the estimated operational cost of establishing and maintaining a unit. 

4. To compare the cost of maintaining two or more units in an organization. 

5. To illustrate a current BDF unit situation with respect to actual cost vs. budgeted 
cost. 

6. To illustrate the BDF overall situation with respect to actual cost vs. budgeted 
cost. 

7. To support decision makers and planners in BDF-HQ for effective and efficient 
resource planning with respect to manpower and operational equipment. 
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B, OBJECTIVE AND RESEARCH QUESTIONS 

The objective of this research is to define, design and implement a prototype 
version of a decision support system (DSS) that addresses the Bahrain Defense Force 
(BDF) requirements for analyzing, establishing and maintaining the organizational 
structures of BDF units. The DSS will combine database technology and optimization 
models. 

The primary research question with respect to this objective is to determine the 
appropriate design heuristics in terms of data, models, and user interfaces for a system to 
support decisions about the creation and maintenance of organizational structures in the 
BDF. There are also several subsidiary research questions: 

1. What are relevant performance metrics for maintaining BDF organizational 
structures of manpower and equipment? 

2. What database architecture is required to support such a DSS tool? 

3. What analytical models are appropriate for developing robust cost models? How 
can software systems supporting such models be integrated with the database 
architecture? 

4. What visualization tools and user interfaces are appropriate for supporting 
decision makers using this DSS? 

C. SCOPE 

The scope of the thesis will include: 

1. Identification of the current processes of analyzing, approving and maintaining a 
BDF unit organizational structure. 

2. Identification and prototyping a suggested database model and DSS interface that 
would satisfy a critical mass of BDF requirements and objectives. 

3. Identification of alternative solutions to such a DSS tool. 

4. Only a prototype will be developed, which can be used to generate requirements 
for a full operational system. It is beyond the scope of this thesis to develop an 
operational system. 
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D, METHODOLOGY 

The methodology used to fulfill the requirements for this thesis will consist of the 
following steps: 

1. Conduct a literature review of books, professional journals, magazines articles, 
web-based materials, and other library information sources. The reviews will 
address topics on decision support systems, database technologies, operations 
research, human resources, costing models, cost-benefit analysis, and military 
organizational structures. 

2. Gather sample data from Planning and Organization Directorate on several 
existing and proposed organizational structures of BDF units to examine the 
functions needed in the proposed system. 

3. Identify user interface requirements by interviewing key users in POD (the 
intended DSS users). The GUI requirements will be in terms of input controls as 
well as output displays such as reports, queries, “what if’ capabilities, and other 
visual displays. 

4. Design underlying database schema that has a complete logical view of the 
database using a software application called Visible Analysis. Once the database 
schema is created and analyzed (normalized), it can then be converted to the 
desired database application such as Microsoft Access. 

5. Identify and build associated cost models using simulation, what-if analysis, 
and/or optimization (linear programming) models. 

6. Build a standalone database prototype in Microsoft Access in which can be easily 
migrated to a client-server database in the future. 

7. Design and implement user interfaces. 

8. Test prototype system. 

E. PRIMARY BENEFIT OF THE STUDY 

This thesis will develop a prototype DSS tool for manpower and operational 

equipment resource planning in support of BDF HQ decision makers and planners. 
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Specifically, this thesis will propose a DSS application which can provide the BDF better 
vision in planning for its current and future organizational structures. The prototype can 
serve as a preliminary requirements specification for a fully operational system in the 
BDF. 

F, THESIS ROADMAP 

The coming chapters will address the following subjects: 

1. Chapter II will provide an overview of the current BDF system of maintaining its 
organizational structures of manpower and equipment that identifies processes of 
analyzing, approving and maintaining those organizational structures. This 
chapter will also address relevant performance metrics used to evaluate BDF 
organizational structures of manpower and equipment, and finally will discuss the 
current system and factors that have led to its suboptimal performance. 

2. Chapter III will discuss a database design that satisfies the critical mass of BDF 
requirements and objectives described in the first chapter. 

3. Chapter IV will develop and illustrate examples of optimization models that can 
be linked to the database model to provide the requisite decision support. 

4. Chapter V will discuss the prototype that has been developed with emphasis upon 
the user interfaces such as input/output forms, queries, reports, and model “what 
if’ analyses. 

5. Finally, Chapter VI will conclude the research and include recommendations for 
future research. Furthermore, the core benefits of applying such a tool will also be 
discussed. 
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II. OVERVIEW OF THE CURRENT BDF SYSTEM OF 
MAINTAINING ORGANIZATIONAL STRUCTURES FOR 
MANPOWER AND EQUIPMENT 


A, INTRODUCTION 

The BDF builds organizational structures to include all manpower and operational 
equipment resources that will be allocated to a unit. The resources of operational 
equipment in a unit are weapons, vehicles, and communication instruments. However, the 
request to study major changes in the organizational structure of an existing unit or 
establishing new ones gets initiated by the BDF top-level positions (i.e. Commander in 
Chief (CINC), Minister of Defense (MOD), Chief of Staff (COS)...etc) for many 
reasons: 

1. BDF needs to develop the organizational structure of its forces according to a 
potential external threat that has arisen to the homeland. 

2. BDF needs to reorganize its forces to be compatible with its friendly forces 
structures. 

3. When BDF plans to receive recent operational equipment (i.e. tanks, ships, 
weapons, radars...etc). 

4. Or when the original mission assigned to a unit has changed and/or expanded in 
such a way that the current organizational structure of that unit does not match 
with the new mission. 

In addition, all proposed structures must be presented to the HQ officials before 
approval. Thus, it is important that the process of creating organizational structures have 
computer-based tools that provide accuracy, efficiency and predictability in presenting 
information which in turn eventually lead to effective decisions. However, at this time the 
current BDF system for maintaining organizational structures of manpower and 
equipments is done manually, and the number of staff assigned in this area is not 
sufficient to handle multiple, complex tasks simultaneously. 

Therefore, the purpose of this chapter is to describe the present process of 
maintaining the BDF organizational structures and the expected performance associated 
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with it. The description of the processes will help to justify the BDF baselines for 
acquiring a decision support system as well as provide specifications for that system. 


B. CURRENT PROCESSES 

The current processes of maintaining the BDF organizational structures are 
illustrated in Figure 1 below. They are somewhat dependent upon each other and involve 
four main steps as follows: 



Figure 1. Current Process for Maintaining BDF Organizational Structures 
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1, Receiving Requests to Study Future Establishment of a New Unit or to 
Reorganize the Structure of an Existing Unit 

A request to alter an existing strueture of a unit or to make slight adjustments to 
that strueture is usually initiated by the unit eommander. Those requests are reeeived on a 
daily basis, whereas orders to study future units eome from the HQ top level oflheers on a 
monthly basis or sometimes weekly basis. 

2, Prioritizing and Scheduling those Studies 

Upon Planning and Organization Directorate (POD) director instructions, only 
studies that require a comprehensive analysis are prioritized and timetabled. Requests that 
need only small modihcations to the structure are directly put into the execution cycle of 
the structure alteration process, once they get the first approval to do so. Moreover, the 
first approval test is part of this process and is applied to quickly determine whether the 
minor changes in a structure are economically and operationally feasible or not. Since the 
focus of this research is to define major current processes for maintaining the 
organizational structures of BDF, the descriptions of minor structure alteration processes 
will be neglected because they are easy to maintain and do not require huge efforts. 


3, Building and Analyzing an Inclusive Structure Study 

To conduct such a study the POD planners must be freed to do one study at a time 
since this process needs a huge amount of time and effort to be achieved. Therefore, this 
step requires decomposing an overall process into sub-processes because it accounts for 
about 80% of the POD planner workload. These sub-processes are as follow: 

a. Preparing the Proposed Hierarchical Structure and Tables of the 
Intended Unit 

The size of the unit determines the time and effort needed to accomplish 
this stage. Normally, the POD staff uses the MS-Office applications to build the proposed 
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unit tables along with other applieations (i.e. FileMaker-Claries) to fabrieate the final 
produet of hierarehical struetures. 

b. Estimating the Running and Fixed Costs of the Structure and 
Comparing it to Similar Existing Units 

The next step is to insert the eomputed number of resourees that has been 
alloeated to the strueture in spreadsheets to generate estimations of the most important 
eost drivers in the strueture. The eosts resulting from manpower resourees have the top 
priority in this sub-proeess beeause it aeeounts for 60% to 70% of the total budget needed 
to run this structure. The manpower cost is determined based upon basic rank salary, 
allowances associated with rank (i.e. transportation, social...etc), and allowances 
associated with job (i.e. position, job type...etc). Additionally, POD planners must gather 
data regarding the initial cost of operational resources such as weapons, vehicles and 
wire/wireless communication devices every time they do this process. Once all 
estimations are calculated, the matching sub-process is started; this is currently done 
manually. When comparing similar existing units to the proposed unit, overstaffed 
structures might appear to the POD staff that require chopping if no justification has 
accompanied it. Thus, when putting the intended structure under a mini-scope that is still 
done by hand might not illuminate tiny and might be major anomalies to that structure. 
Then, a careful feasibility check is done before proceeding to the next step. If this test is 
not passed, then the structure must be modified and fed back to the preparing sub-process 
again. Moreover, unique proposals need experts to decide on the maximum ceiling of the 
organizational structure for this kind of unit. Customarily, a committee headed by the 
POD director is responsible to conduct such studies that recommend more than one 
option for the unit structure. 


c. Setting up the Structure Information for the Briefing, and then 
Presenting it to HQ 

After editing the proposed hierarchical structure and finalizing it, the POD 
staff translates those structures into multi-format tables that hold numbers of manpower 
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and operational equipments and the costs related to them in order to brief the BDF-HQ 
oflhcials. To generate those tables that hold estimations of fixed and running cost of the 
intended structure, a substantial computing job must be done to give a clear picture to the 
decision-makers group. Obviously, this stage is critical and the presentation contents need 
to be well-organized with all cost drivers tailored to reasonable figures within the BDF 
budget in order to persuade the necessary decision makers. Usually before presenting the 
final product of a proposed unit, a POD director directs his planners to work within 
boundaries and constraints of how a proposed structure might look and what parts of the 
structure need to be focused upon. Finally, either an approval feedback is returned to the 
POD director, or further studying is needed. In the first case, the POD planners are still 
responsible to complete the work they have started and submit the final official draft of 
the proposed unit to be signed by the BDF CINC. In the second case, the POD planners 
need to rework the whole study and repeat the preparation and analysis process to include 
modifications that have been approved during the presentation and/or additional 
suggestions for the proposed unit. 

d. Archiving All Studies and Distributing Copies Among BDF 
Directorates 

This process is essential to keep performing all future structure studies that 
require information about previous endorsed structures and rejected ones as well for 
comparison purpose. Currently, a hardcopy of any approved structure and its related 
tables are kept in the POD cabinet whereas softcopy is saved in a dedicated hard disk 
with floppy disks as a backup. However, a unit organizational structure could have 
several files of different types. For instance, MS Word files contain unit mission, unit 
roles, and unit job description for the jobs it currently has, MS PowerPoint or FileMaker 
files contain all hierarchical structures of that unit, and finally, MS Excel files contain all 
information about unit tables such as different formats of manpower list, weapon list, etc. 
All BDF-HQ directorates and the commander of that unit must receive a hard copy 
through the regular BDF mail system. 
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C. PERFORMANCE METRICS 

During the study stage of establishing new unit strueture, there are two primary 
performanee metrics of effectiveness that decision makers use to decide which 
organizational structures are better (or worse) than others. These measures are taken into 
account by POD planners to verily how feasible and reliable is the unit structure before 
supporting the idea of endorsing this structure. The measures are as follows: 

1. Unit Structure Outlay Costs 

Theses can be either fixed costs or running costs resulting from creating a unit 
structure that requires resource allocations in order to operate according to the unit’s 
assigned missions. The fixed costs involve expenditures that are paid once during the unit 
lifecycle, and which are also considered as the unit’s assets. For instance, building unit 
facilities, purchasing unit weapons and vehicles are examples of the fixed costs 
associated with establishing a BDF unit. The running costs concern expenditures that are 
paid periodically (weekly, monthly or annually) during the whole unit lifecycle to make 
the unit fully operational. Examples of unit running costs are manpower costs (such as 
salaries, allowances, promotions and family health care expenses), training costs, 
ammunition costs, and maintenance costs of the equipments.. Therefore, the POD 
planners try to achieve a cost-effective unit structure which will stay within the BDF 
budget constraints, and will not exceed it under the assumption that no new operational 
equipment is intended to be purchased in the near future. 

2, Unit Structure Quality 

This measure means operationally how feasible or practical is the unit structure 
before implementation. Does it serve the assumed unit roles and tasks? Different tests 
conducted by POD planners to verify this measure are as follows: 
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a. Combat Doctrine Test 

The unit structure must initially comply with the BDF combat doctrine. 
For example, an infantry battalion must be comprised exactly of three infantry 
companies, one supporting company, and one administrative company. Each infantry 
company encompasses three infantry platoons. 

b. Category Test 

The unit manpower is divided into three major categories: operations, 
administrative, and technical manpower. The unit type can only determine the minimum 
and the maximum manpower percentages that will be assigned to each category (i.e. field 
artillery battalion can have 70-80% for operation vacancies, 15-25% for administrative 
vacancies, and 5-10% for technical vacancies). Thus, POD planners try to define those 
interval constraints for each model and adhere to them as much as possible to obtain a 
robust unit structure. 


c. Military Standard Test 

The unit structure must obey the military standards in filling the jobs 
required to operate and maintain a certain weapon or vehicle. Also, POD planners use 
friendly forces structures, if available, as a reference when creating such unit structures. 

d. Rank Distribution Test 

Finally, the unit structure ranks must be shaped as a pyramid for both 
officers and enlisted ranks as shown in Figure 2 below. In the enlisted case for instance, 
the number of corporal ranks (third lowest rank) must always be greater than (best 
scenario) or at least equal to (worst scenario) the number of sergeant ranks (fourth lowest 
rank). Again, the unit type can only determine a rank’s intervals. 
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Figure 2. Ordering the BDF Ranks Distribution 


As a result, the typical unit structures are those which best satisfy both 
performance measures mentioned above, and POD planners use those measures when 
comparing two or more of BDF unit structures to determine which is better. 

D. CURRENT SYSTEM PERFORMANCE 

BDF-HQ is always willing to update or establish new organizational structures of 
its forces, reengineer its business processes, and adopt technologies whenever that is 
deemed best for BDF. In general, the overall performance of the current BDF system of 
maintaining its organizational structures is not efficient and effective enough to support 
concurrently the BDF development process and its ambitious perspectives. There are 
many reasons or factors that have led to such weak outcome of this system; 

1, Shortfall of POD Planners 

As mentioned before, the number of POD planners and staff is not sufficient to 
handle the nonstop, increasing workload. This degrades the overall performance of that 
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system. Subsequently, the eurrent POD statf can conduct only one comprehensive study 
at a time, and the related outcome is often not sufficient to achieve any but the minimum 
requirement. The recommended solution to solve this problem will be discussed in 
chapter 4. 

2, No Embedded Computer-Based System in the Current Processes 

BDF-HQ has owned personal computers, servers and mainframe computers since 
the late 1980’s and started networking them shortly thereafter. However, the POD system 
of maintaining the BDF organizational structures does not fully utilize computer 
capabilities to achieve maximum, or even moderate benefits. For example, a computer- 
based system can be built to hold customized business rules that control and validate 
actions taken by the system users. Consequently, the lack of using an automated tool such 
as a decision support system has prevented the current POD system from considering 
more potentially useful decision alternatives. The benefits of a DSS include the 
following: 

1. Discourage premature decision-making and alternative selection. 

2. Generate multiple and higher quality alternatives for consideration. 

3. Improve response time of decision maker. 

4. Explore and test multiple problem-solving strategies. 

5. Increase the decision maker’s ability to tackle large scale and complex problems. 

6. Explore multiple analysis scenarios for a given decision context. 

7. Improve the reliability of a decision process outcome. 


3. Several Data Files are Used to Maintain One Unit Structure 

This is a big dilemma in the current system which needs additional file processing 
efforts to retrieve data, create reports and so forth. By splitting and isolating the data in 
many files, the following drawbacks may occur in the system performance: 
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a. Data Integrity Degradation 

For instance, if a change is made in one file of a unit structure, then POD 
planners must manually feed all subsequent updates in the remaining files that contain the 
same information about that unit. Actually, entering data more than once will increase the 
data error probability, and much of the data is duplicated. 

b. Integration and Speed Problems 

Since there is no real or virtual link between data files that contain 
information about all BDF structures, POD planners have to do extra work to integrate 
those files to extract common reports needed to enhance the decision-making process in 
maintaining the BDF organizational structure. 


c. The Difficulty of Presenting Data in the POD User ’s Perspective 
It is dilficult to present separate file data in a form that seems natural to 
POD planners and decision makers. This complexity arises because with manual file 
processing, data relationships must be maintained which is not an easy task to do. Also, 
making queries based on certain or set of criteria is time-consuming in the current 
situation. 

4, Lack of Using Analysis Techniques in the Current System 

Presently, POD does not implement any kind of analysis strategies (i.e. 
simulation, forecasting, linear programming and what-if analysis tools) in order to obtain 
optimum numbers of resources allocated to a unit. In fact, if these capabilities were used 
in the current system, POD could effectively reduce cost and achieve better quality output 
in establishing and maintaining a unit organizational structure. Thus, without having such 
techniques in the POD system, a quantum performance will never be reached. 

In a nutshell, the aforementioned factors highlight some of the system 
shortcomings in maintaining BDF organizational structures. The current situation is 
almost completely manual, and does not automate any part of the system processes in a 
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way that could lower BDF cost and enhance the speed and the quality of building and 
updating BDF structures. 

The first step in designing a DSS to support the requirements outlined above is to 
identify the data requirements and an associated database structure for housing the data. 
In the next chapter, we will analyze and design a database model that meets the BDF data 
requirements and objectives. The database design will flow from the performance metrics 
described above. 
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III. THE DATABASE MODEL 


A. INTRODUCTION 

The objective of this research is to propose a decision support system (DSS) 
solution that addresses the Bahrain Defense Force (BDF) needs for analyzing, 
establishing and maintaining the organizational structures of BDF units in order to 
facilitate more effective decision-making processes in that area . The DSS solution will 
be built on top of an automated database application that contains all information 
required for establishing the costs of building and maintaining an operational military 
unit. This in turn will allow BDF decision-makers and planners to track and monitor the 
manpower, staffing, and operational support requirements, and to propose or approve a 
cost-effective, quality organization structure. 

The components of a DSS can generally be classified into three distinct parts: 
data, models, and user interface. [Ref. 1] The data component of a DSS is where the 
various activities associated with retrieval, storage, and organization of the relevant data 
for the particular decision context are managed. Additionally, the data management 
system provides for the various security functions, data integrity procedures, and general 
administration duties associated with using the DSS. The model component is similar to 
the data component in performing the retrieval, storage, and organizational activities 
associated with the various quantitative models that provide the analytical capabilities for 
the DSS. Finally, the user interface is a key element in DSS functionality. It provides the 
vehicle through which the user navigates through the DSS, views output displays and 
performs what-if analyses. 

This chapter will focus mainly on the DSS data design phase, which emphasizes 
development of a conceptual data model that fulfills the requirements. However, in order 
to clarify the system design, this chapter will start with a brief discussion about the 
system or prototype analysis to outline the investigation of the problem and requirements 
(functional and interface requirements). 
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B, ANALYSIS PHASE 

The BDF DSS system must embrace a database application along with an 
embedded DSS interface. Therefore, the database tool must be designed to meet the BDF 
functional requirements and support the DSS user interface requirements as follows: 

1. Establish an organizational structure that satisfies manpower and operational 
equipment requirements (vehicles and weapons) of an organization. The database 
structure must segregate the unit entity from the resources entities and create 
relationships among each in order to facilitate the appropriate database 
management. 

2. Track and highlight the staffing requirements of the new and/or existing 
organizations. The database shall allow the computation of manpower shortfalls 
or surpluses in a selected unit or an organization as a whole. This database 
application feature will enable the decision-makers to execute informed and 
responsive changes to manpower recruitment and retention policies when needed. 

3. Compute the estimated operational cost of establishing and maintaining a unit 
based on resources allocated to that unit. The database shall automatically 
calculate all cost drivers for an existing unit structure or a proposed one. 
Additionally, the calculated cost drivers for a unit structure must accompany any 
changes made to the unit resources. In other words, the DSS user can see the 
instant cost impact whenever he/she makes modifications in the unit resources. 

4. Compare the cost of maintaining two or more units in an organization. The model 
must allow the DSS user to visualize and present cost information in different 
ways, e.g. numerical or graphical presentations. 

5. Illustrate a current BDF unit situation with respect to actual cost vs. budgeted 
cost. The database must allow the DSS user to see the difference between the unit 
actual cost and the unit planned cost. 

6. Illustrate the overall BDF situation with respect to actual cost vs. budgeted cost. 
The database must differentiate the approved unit structures from the proposed 
ones in order to estimate the BDF overall cost situation (current or actual cost vs. 
planned cost). 
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7. Support decision makers and planners in BDF-HQ for effective and efficient 
resource planning with respect to manpower and operational equipment. This 
requirement symbolizes the ultimate BDF goal in designing the database model 
which should provide its users with the following capabilities: 

a. Analytical models that can be built-in or linked to the database 
application. These models are: 

1) Optimization models that help to find the best solutions for cost 
and manpower based on user-defined constraints. The next 
chapter will discuss this point in more detail. 

2) Simulation of an existing or proposed unit structure in the 
database by providing a tool to duplicate the unit information and 
related resources but with a different unit identity. This process 
will widen the unit structure alternatives and help to obtain the 
desired cost and quality in the unit structure under study. 

3) What-if models that help to meet the desired specification of the 
suggested unit structure in a short time. The what-if technique 
can be described as sensitivity analysis that allows generation of 
different unit structure scenarios that trigger automatic 
computations whenever a change is made to the unit resources. 

b. Visualization tools and graphical representations such as pivot tables and 
charts can be utilized when comparing two or more of unit structures. 

c. Defining and creating queries and reports in formats that are in accordance 
with the users’ needs. This will support the demonstration process of the 
proposed unit structure. 

C. DATABASE DESIGN PHASE 

The process for building the BDF DSS data component is Analysis (Logical 
Design), Physical Design, and Process Design. 
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1. Logical Design of BDF DSS 

The conceptual data model can be created accordingly from the previously 
defined database requirements. As shown in Figure 3 below, the main entities for this 
model are Unit, Manpower, Weapons, Vehicles, Jobs and Salaries. Their associated 
primary keys, attributes, and relationships are defined in the Entity-Relationship (ER) 
diagrams shown in Appendix A. The standard forms (normalization), entity integrity and 
referential integrity rules were considered when building this data model to achieve data 
consistency and at the same time to avoid update, insertion, and deletion anomalies. 
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Eigure 3. Entity Relationship Diagram of the Database Model (BDE DSS) 


There is a vast amount of information and literature available in the area of 
relational database design. Therefore, the following definitions are provided for clarity: 

Relation is a table, or flat file, with columns and rows 
Relation attribute is a column in a relation. 

Primary key is one or more attributes, the value(s) of which uniquely identify 
each row in a relation. 
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Composite Key is a primary key consisting of more than one attribute. 

Foreign key is a set of attributes in one relation that constitute a key in some 
other (or possibly the same) relation; used to indicate logical links between 
relations. 

Entity integrity rule states that no key attribute of any row in a relation may 
have a null value. 

Normal forms are rules for structuring relations that eliminate anomalies. 

Referential integrity rule states that the value of a non-null foreign key must be 
a primary key value in some relation. 

Update anomaly refers to the data inconsistency resulting from data redundancy 
and partial updates. 

Deletion anomaly refers to the unintended loss of data due to deletion of other 
data. 

Insertion anomaly refers to the inability to add data to the database due to the 
absence of other data. 

Integrity constraints are rules that restrict the values that may be present in the 
database. Codd’s relational data model includes several constraints that are used 
to verify the validity of data in a database as well as to add meaningful structure 
to the data. [Ref. 2] 


The entities and relationships in this model are developed via the Visible 
Analyst™ application that allows a subsequent examination of each relation to assure it 
follows desirable normalization criteria. Visible Analyst can also generate easily the 
database schema shown in Appendix B that defines the database structure, its tables, 
relationships, domains, and business rules. [Ref 3] The main entities are described as 
follows: 


a. Unit Entity 

The most important entity (central entity) in this model is the unit since 
the total cost of establishing a unit or organization is derived from the other secondary 
entities such as manpower, vehicles, etc. In other words, the unit entity acts as the unit 
repository that holds information about all BDF unit resources which a BDF unit needs. 
The primary key of this entity is the unit identification number (Unit ID). 
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b. Manpower Entity 

This entity represents the model human resource planning part which in 
fact is the most costly resource that a BDF must consider when establishing new units. 
Hence, it is the second most important entity, which holds all job information and their 
related costs for a BDF unit. This entity has three relationships with Unit, Jobs and 
Salaries entities. First, many Unit manpower instances (rows) in the Manpower entity 
will be linked to one instance from Unit entity. On the other hand, many Jobs and Ranks 
instances can be shared by many Units assuming the unit ID, rank and the job type are 
not repeated in Unit manpower. This means that the key of manpower entity is the 
combination of unit ID, rank and the job type. Accordingly, the unit manpower data can 
be constructed based on both Salary and Job entities that have information about current 
BDF jobs and their estimated costs, which includes basic salaries and allowances. 
Therefore, linking those entities to the manpower entity is essential in order to share one 
source of current BDF jobs and one source of salary-based ranks data. In addition, the 
Manpower entity must hold two essential properties (attributes) that specify the available 
and occupied number of jobs in a unit. The first will correspond to the budgeted number 
of jobs; whereas the second will represent the actual number of jobs (current manpower 
situation of a unit), and finally the difference between them will correspond to the 
shortfall or surplus. 


c. Vehicles and Weapons Entities 

Both entities have similar attributes and primary keys. They symbolize the 
resource catalogs of BDF operational equipment which a BDF unit needs. In addition, the 
costs established for those entities include not only the fixed costs for a type of vehicle or 
weapon but also the running cost to maintain it. All existing and proposed BDF units will 
share those entities as needed but in different quantities via the indirect many-to-many 
relationships depicted in Appendix A. As a result, two associative entities are required 
between Vehicle/Weapon and Unit entities to create a many-to-many relationship. Those 
entities are called Unit Vehicles and Unit Weapons. The primary key of Unit_Weapons 
for example, is the weapon type plus unit ID. 
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In summary, the resources entities are structured in a way that all proposed 
and approved BDF units will share the BDF job dictionary, BDF salary and allowance 
tables, and BDF vehicle and weapon catalogs. As a result, this will minimize redundancy 
of information and make the database run more efficiently during execution of the DSS. 

2, Physical Design of BDF_DSS 

The database schema can be transformed to the relational database design in a 
desired target DBMS which in our case will be MS Access™. MS Access™ provides the 
underlying database management functions and features needed for designing the 
BDF DSS. The relational structure diagram of the BDF DSS and the properties of the 
relationships are depicted in Appendix C. In the relational structure diagram, each entity 
(relation) in the ER diagram is translated to a table which has a primary key or composite 
key that uniquely identifies each row (record) in that table. The second part of Appendix 
C depicts all the relationships and the related properties established between the tables. 
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Figure 4. Entity Relationship Diagram of the Database Model - Primary Key Level 


23 



































3. Process Design of BDF DSS 

Initially, the process will commence when POD planners want to compute the 
fixed and recurring cost of setting up a BDF unit and compare it with other existing units. 
The database structure enforces the referential integrity constraints in all relationships to 
assure data reliability. Consequently, the data model requires that data entry sequentially 
follow the steps outlined below; otherwise, the user will encounter error messages from 
the related built-in business rule if a precondition of data entry is not satisfied: 

a. The database user must first specify the unit identification number, unit type, unit 
size, and whether it is an existing BDF unit or a proposed BDF unit (i.e. 101 
approved artillery battery, 104 approved armor battalion, 114 proposed infantry 
brigade... etc). 

b. Before building the unit manpower, all jobs that are required in the new BDF unit 
must first be in the BDF job dictionary. In other words, a Job Type in Jobs table 
must exist first in order to add the same JopType in Manpower table. 

c. Before building the unit manpower, all ranks that are required in the new BDF 
unit must be in the BDF salary table. Similarly, a Rank in Salaries table must exist 
first in order to add the same Rank in Manpower table. 

d. Before building the unit vehicles and weapons, all vehicle and weapon types that 
are required in the new BDF unit must be in the BDF vehicle and weapon 
catalogs. For example, a VehicleType in Vehicle table must exist first in order to 
add the same VehicleType in Vehicle Units table. 

e. Finally, the physical design enforces two important relationship properties that a 
BDF DSS user must be aware of while maintaining the data. These are the 
cascade update related fields and the cascade delete related records. Cascade 
update related fields allow the BDF DSS users to update primary key fields in a 
parent table and automatically update all related fields in associated child tables. 
Cascade delete related records will delete all child records once their parent 
record has been deleted. 

In addition, the database has many capabilities that fulfill the BDF DSS 
requirements which are stated in the system analysis phase. For instance, the database can 
instantly compute the unit statistics based on hidden equations built-in via database 
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macros once a modification to the unit resources oeeurs. When the applieation user 
modifies a unit weapon reeord for example, subsequent changes will oecur in the unit 
reeord for both Weapon Total Cost and Weapon Maintenanee Cost fields. However, this 
proeess will only be allowed through the BDF DSS analysis menu that manipulate 
proposed unit structures to generate more scenarios and at the same time avoid alterations 
on existing unit structures. 

The seeond component in designing a DSS is to develop the analytical models 
that will be utilized in the BDF DSS. In the next ehapter, we will introduee two examples 
of applications of optimization models whieh comply with the performance metries 
described in earlier ehapter. The ehapter will cover the eonstruetion cyele of eaeh model 
and explain it step by step. 
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IV. THE OPTIMIZATION MODELS 


A. INTRODUCTION 

Our world is filled with limited resourees. The amount of oil we ean pump 
out of the earth is limited. The amount of land available for garbage dumps and 
hazardous waste is limited and, in many areas, diminishing rapidly....Deeiding 
how best to use the limited resourees available to an individual or a business is a 
universal problem. In today’s eompetitive business environment, it is inereasingly 
important to make sure that a eompany’s limited resourees are used in the most 
elfieient manner possible. Typieally, this involves determining how to alloeate the 
resourees in sueh a way as to maximize profits or minimize eosts. [Ref 4. Seet. 
2.0-16] 

Mathematieal programming (MP) is part of a larger field of management seienee 
ealled operations researeh that finds the optimal, or most elfieient, way of using limited 
resourees to aehieve the objeetives of an individual or a business. For this reason, 
mathematieal programming is often referred to as optimization. [Ref. 5] 

Optimization eovers a broad range of problems that share a eommon goal, namely 
determining values for deeision variables in a problem that will maximize (or minimize) 
some objeetive funetions while satisfying various eonstraints. Constraints impose 
restrietions on the values that ean be assumed by the deeision variables and define the set 
of feasible options (or the feasible region) for the problem. Aeeordingly, the linear 
programming (LP) problem represents a speeial eategory of MP problems in whieh the 
objeetive funetion and all the eonstraints ean be expressed as linear eombinations of the 
deeision variables. [Ref 6] 

This ehapter will present two optimization models whieh will be part of the 
BDF DSS. These models are essential for the required DSS in order to satisfy the eost 
and quality performanee metries deseribed in ehapter 2. This ehapter also explains in 
detail how to ereate and maintain optimization models that support BDF deeision-makers. 


B, INFANTRY BATTALION MODEL 

Before deseribing this model, we will first implement a general form of the 
problem-solving proeess in order to best understand and visualize how modeling fits into 
the entire BDF DSS problem. [Ref. 7] As shown in Figure 4 below, the problem-solving 
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process consists of five major steps. For each step below, we will describe the BDF- 
specific circumstances which are relevant and the appropriate sub-processes which 
comprise it if any. 



Figures. Visual Model of the Problem-solving Process (From Ref 4) 

1, Identify Problem 

The BDF wants to optimize its budget when establishing or maintaining a unit 
structure that has associated resources and costs. At the same time, BDF also wants to 
make that unit structure as effective as possible so that it will produce at maximum 
throughput. The first BDF demand emphasizes the cost performance metric of the unit 
structure, whereas the second one focuses on the quality performance metric of the unit 
structure (see chapter 2). As a result, we can precisely define the BDF problem as 
follows: “BDF wants to achieve simultaneously a cost-effective and high quality unit 
structure which respectively captures efficiency and effectiveness measures of the unit 
structure.” 

2, Formulate and Implement the Optimization Model 

The formulation process is better described as “brainstorming the model”. We will 
create the manpower optimization model of the infantry battalion step by step as follows: 

a. Defining the Decision Variable 

The decision variables that we wish to compute are the numbers of all 
ranks required in an infantry battalion structure. Therefore, we can refer to the ra nk s with 
the equivalent military standard symbols as the following: 
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01 refers to # of Lieutenant Oflfieer 

02 refers to # of 1®* Lieutenant Officer 

03 refers to # of Captain Officer 

04 refers to # of Major Officer 

05 refers to # of Lt Colonel Officer 

06 refers to # of Colonel Officer 

E7 refers to # of Warrant officer (Enlisted rank) 

E6 refers to # of 2"‘* Warrant 
E5 refers to # of Sergeant Major 
E4 refers to # of Sergeant 
E3 refers to # of Corporal 
E2 refers to # of Eance Corporal 
El refers to # of Private Soldier 
CIV refers to # of Civilians 

b. Defining the Objective Function 

The objective function is to maximize the total number of ranks 
(optimized ranks) subject to the maximum budget that the BDE can afford. The budget 
ceiling will be the first restriction included in the constraints part. Therefore, the objective 
function is: 


Maximize: 01+02+03+04+05+06+E1+E2+E3+E4+E5+E6+E7+CIV 


c. Defining the Constraints 

Several types of constraints affect this model. 


Budget Constraint: BDE will estimate the maximum budget that it can 
afford to establish an infantry battalion when it determines the average spending on 
existing similar unit structures. We will name the estimated maximum budget as T which 
is an input field (user-defined). We obtain the optimized total annual salary for the 
infantry battalion by multiplying the number of each rank (optimized rank) and the 
correspondent monthly basic salary by 12, and then summing these values. As shown in 
the formula below, the constraint is that the optimized total annual salary should be less 
or equal to the estimated maximum budget (T). 

[(06*4500) + (05*4000) + (04*3500) + (03*3000) + (02*2500) + 

(01*2000) + (E7*1500) + (E6*1300) + (E5*1100) + (E4*900) + (E3*700) + 
(E2*500) + (El*400) + (CIV*300)] * 12 <= T 
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Default Constraints: Certain ranks in the BDF must be allocated exactly, 

either by default according to BDF regulations. Additionally, the user can define those 

values dynamically to override the BDF defaults. Those are as follows: 

06=1 (#ofCOL=l) 

05 = 6 (# of LTC=6) 

04 = 14 (# of MAJ=14) 

E7 = 7 (# of WAR=7) 

Budget Allocation Constraints: This type of constraint will divide the 
optimized total annual salary into officer (OS or officers salaries), enlisted (ES or enlisted 
salaries), and civilian (CS or civilian salaries) groups to be matched with user-defined 
percentages. The percentages will be automatically multiplied by the estimated maximum 
budget (T) which will then correspond to the maximum budget allocation to each group. 
As stated in the formula below, for each group, the constraint is that the group optimized 
total annual salary should not be greater than the corresponding maximum allocation of 
the budget. 

0S<= 20% of T 
ES<= 78% of T 
CS<= 02% of T 

Manpower Allocation Constraints: Similar to the budget allocation 
constraints, this constraint separates the optimized total ranks into officer (OM or oificers 
manpower) and enlisted plus civilian (ECM) groups to be matched with user-defined 
percentages. In the first case, a percentage of 4% will be automatically multiplied by the 
optimized total ranks which should be less than, or equal to, the optimum number of 
officer ranks. In the second case, a percentage of 96% will be automatically multiplied by 
the optimized total ranks which should be greater or equal than the optimum number of 
enlisted plus civilian ranks. These two percentages will be user-specified to allow 
flexibility in the model. 

OM >= 04% of Manpower (4% of the total optimized manpower) 

ECM <= 96% of Manpower (96% of the total optimized manpower) 
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Upper and Lower Boundary Constraints: This set of eonstraints will foree 

the rank numbers to be shaped as a pyramid in whieh they obey one of the performance 

measures stated in chapter 2. For the enlisted infantry battalion ranks, we wish to separate 

adjacent ranks from each other. For example, the number of the E6 ra nk must be at least 

two times that of the number of the E7 rank which is a user-specified parameter and not 

more than four times that of the E7. However, we can set the upper bound only for the 

last rank, El, to be not more than four times that of E2 because we do not know how 

much will be left from the budget to cover the last rank. Additionally, to meet the BDE 

default in distributing the lowest officer’s ranks, we presumed that the number of 01 is 

less or equal than the number of 02 and the number of 02 is less or equal than the 

number of 03. Thus, for an infantry battalion, we set the upper bound factor to be 4 and 

the lower bound factor to be 2 as seen in the equations below. 

2*E7 <= E6 <= 4*E7 (i.e. for E7=7 then 14<=E6<=28) 

2*E6 <= E5 <= 4*E6 
2*E5 <= E4 <= 4*E5 
2*E4 <= E3 <= 4*E4 
2*E3 <= E2 <= 4*E3 
El <=4*E2 
01 <= 02 
02 <= 03 

Integrality conditions: We must embed this constraint to ensure integer 
values and avoid fractions in all of the optimized ranks. Besides, all ranks must be greater 
than zero to obtain nonnegative solutions. Clearly, this is an integer programming model 
strictly speaking, rather than a linear programming model, although one can do away 
with the integer constraints and just round (up or down) the resultant values to the nearest 
whole number in order to utilize as much as possible of the allocated budget (T). The 
constraint is as follow: 

All ranks are Integer and >=0 

d. Implement the Model 

Having identified the problem and formulated the model, we turn our 
attention to implementing the model. We have selected MS Excel to present our model 
since it is the most popular spreadsheet application and it is widely available. Appendix 
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D shows the model and the generated reports related to the model. To get a reliable, 
auditable and modifiable spreadsheet design, we followed the guidelines stated in the 
Spreadsheet Modeling and Decision Analysis textbook. [Ref. 4] Briefly, these guidelines 
are as follows: 

1) Organize the data, then build the model around the data. 

2) Do not embed numerie eonstants in formula. 

3) Things whieh are logieally related (e.g., left-hand sides and right-hand 
sides of eonstraints) should be arranged in elose physieal proximity to one 
another and in the same eolumnar or row orientation. 

4) A design that results in formulas that ean be eopied is probably better than 
one that does not. 

5) Column or row totals should be in elose proximity to the eolumns or rows 
being totaled. 

6) The English-reading human eye seans left to right, top to bottom. 

7) Use eolor, shading, borders and proteetion to distinguish ehangeable 
parameters from other elements of the model. 

8) Use text boxes and eell eomments to doeument various elements of the 
model. 

3, Analyze the Model 

After verifying that the spreadsheet model has been implemented aeeurately as 
illustrated in Appendix D, the next step in the problem-solving proeess is to eheek that 
the model is doing exaetly what it was designed to do (i.e. the optimized values are 
always within the eonstraints that have been speeified). The main foeus of this step is to 
generate and evaluate alternatives that might lead to the best solution of the problem. This 
involves playing out a number of seenarios or asking several “What if’ questions. 
Spreadsheets are partieularly helpful in analyzing mathematieal models in this manner. 
Generally, “What if’ questions imply loosening or tightening the eonstraints, adding 
more eonstraints, or deleting previous eonstraints as needed. However, in this model, it 
should be fairly simple to ehange some of the assumptions in the model to see what might 
happen in different situations. 


32 



4, Test Results 

The process of analyzing a model does not always provide a solution to the actual 
problem being studied as in our case. As we analyze a model by asking various “What if’ 
questions, it is important that a BDF DSS user be able to test the feasibility and quality 
of each potential solution. We know that an optimal solution derived from the model can 
exhibit known LP problem anomalies (i.e. more than one solution can be obtained, and 
degeneracy, the condition which gives different interpretations of the values on the 
sensitivity report that cannot be relied upon); therefore, the BDF_DSS user must know 
how to read the sensitivity report generated by Excel in order to see how sensitive the 
solution is and if is it applicable or not. [Ref. 8] 

Fortunately, MS Excel provides a help tool to assist the user in reading the 
sensitivity report in an appropriate way. This tool is called the Sensitivity Assistant Add¬ 
in and can be installed by copying the Sensitivity.xla file from the MS Office CD-ROM 
to the folder on the hard drive that contains the Solver.xla (In most cases, this will be the 
folder C:\Program Eiles\Microsoft Office\Ofiice\Library\Solver). [Ref 4] Then by 
following the steps below, the user can utilize the mentioned tool when needed: 

a. In Excel, click Tools, Add-Ins 

b. Click the Browse button. 

c. Eocate the Sensitivity.xla file and click OK. 

Therefore, to check the model validity, users must always conduct a sensitivity 
analysis about the model assumptions whether they reflect reality by either negotiating 
those assumptions with the domain experts and decision makers of BDE or comparing 
them with the assumptions of similar unit structure of friendly forces. 

5. Implement the Solution 

The last step of the problem-solving process, implementation or presentation, is 
often the most difficult. In other words, the BDE DSS users still have to convince the 
BDE top level decision-makers that the solutions they found when constructing the 
proposed unit organizational structure are worthy of implementation in the real world. 
The BDE DSS users can always use the visualization tools provided in the BDE_DSS 
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application (i.e. charts and pivot tables) in concert with the optimization models when 
presenting their arguments. Therefore, a well-organized and elear presentation to the BDF 
top level deeision-makers may help to obtain the initial approval in implementing a sound 
proposal for a unit strueture. 

C. ARMOR BATTALION 

When building this model, we followed the same sequence of the problem-solving 
proeess used in the previous one. However to avoid redundaney, we will address only the 
differences that oecur in this model. The steps in ereating the Armor battalion 
optimization model were the same as the Infantry battalion exeept for the following: 

1. Identify Problem 

The BDF goal whieh was deseribed in the first model was to aehieve a cost- 
eflfeetive and a high quality BDF unit strueture. However, we have assumed that the BDF 
representatives have looked at the first model and their feedbaek question has been: “Can 
we achieve more quality than this?”. Thus, this model will focus upon higher quality in 
the unit strueture whieh is one of the major performance measures that impaet the 
strueture seore in addition to the strueture cost. 

2, Formulate and Implement the Optimization Model 

To achieve the goal of obtaining a higher quality in the unit strueture, we have 
ineluded another feature in this model to attain the quality needed. As explained in 
chapter 2, this feature is to inelude the BDF unit’s manpower categories in the BDF DSS. 
Earlier, we said that those manpower categories are operation, administrative, and 
teehnieal positions and eaeh type of unit has eertain ranges that should not be exeeeded. 
Therefore, this model will be a seeond version of the first whieh handles the dilemma of 
how to optimize the number of categories neeessary in the unit structure along with other 
constraints demonstrated previously. 


34 



a. Defining the Decision Variable 

This model requires more deeision variables since we set apart the 
manpower into three groups. Consequently, we will multiply the 14 different ranks as 
defined in the infantry battalion structure by three to get a total of 42 decision variables as 


shown bellow: 

06 ranks for operation 
05 ranks for operation 
04 ranks for operation 
03 ranks for operation 
02 ranks for operation 
01 ranks for operation 
E7 ranks for operation 
E6 ranks for operation 
E5 ranks for operation 
E4 ranks for operation 
E3 ranks for operation 
E2 ranks for operation 
El ranks for operation 
Civ ranks for operation 


06 ranks for administration 
05 ranks for administration 
04 ranks for administration 
03 ranks for administration 
02 ranks for administration 
01 ranks for administration 
E7 ranks for administration 
E6 ranks for administration 
E5 ranks for administration 
E4 ranks for administration 
E3 ranks for administration 
E2 ranks for administration 
El ranks for administration 
Civ ranks for administration 


06 ranks for technical 
05 ranks for technical 
04 ranks for technical 
03 ranks for technical 
02 ranks for technical 
01 ranks for technical 
E7 ranks for technical 
E6 ranks for technical 
E5 ranks for technical 
E4 ranks for technical 
E3 ranks for technical 
E2 ranks for technical 
El ranks for technical 
Civ ranks for technical 


b. Defining the Objective Function 

The Objective function is to maximize the total number of ranks including 
all categories (optimized ranks) to as the extent the estimated budget (T) allows. In other 
words, this objective will embrace the same concept of the infantry battalion model in 
trying to use as much of the allocated budget as possible. Therefore, the objective 
function is: 

Maximize: 

[01+02+03+04+05+06+E1 +E2+E3+E4+E5+E6+E7+CIV]ops + 

[01+02+03+04+05+06+E1 +E2+E3+E4+E5+E6+E7+CIV]Admin + 

[01+02+03+04+05+06+E1 +E2+E3+E4+E5+E6+E7+CIV]Tech 

c. Defining the Constraints 

The only added constraints in this model are two types and the rest were 
modified accordingly. Those are as follow: 

Category Constraint: The model will give the user the ability to assign a 
range of certain percentages (user-specified values) of the total manpower to each 
manpower category in the Armor battalion. This means that each category of the required 
manpower will have upper and lower bounds to fit in. The conditions are: 
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[01+02+03+04+05+06+El+E2+E3+E4+E5+E6+E7+CIV]ops > 70% of total manpower 
[01+02+03+04+05+06+El+E2+E3+E4+E5+E6+E7+CIV]ops < 80% of total manpower 
[01+02+03+04+05+06+E1+E2+E3+E4+E5+E6+E7+CIV] Admin > 3% of total manpower 
[01+02+03+04+05+06+El+E2+E3+E4+E5+E6+E7+CIV]Admin< 10% of total manpower 
[01+02+03+04+05+06+E1+E2+E3+E4+E5+E6+E7+CIV] xech > 5% of total manpower 
[01+02+03+04+05+06+E1+E2+E3+E4+E5+E6+E7+CIV] xech < 16% of total manpower 


Default Constraints: As a subsequent eonstraint to the eategory restrietion, 
this eondition must be included in the model to ensure that the BDF standards in the 
number of officer ranks in each category will not be violated. Those ranks must be 
exactly defined and cannot be optimized in an Armor battalion structure. Those defaults 
are as follow: 


06= 1 (as operation Colonel) 

05= 6 (5 as operation LTC, and 1 as Admin LTC) 

04= 10 (8 as operation MAJ, 1 as Admin MAJ, and 1 as Tech MAJ) 

03 are neither Admin nor Tech CAPT’s 

02 are neither Admin nor Tech LT’s 

01 are neither Admin nor Tech LT’s 

E7 = 7 (will remain the same as in the first model) 


Upper and Lower Boundary Constraints: This set of constraints follows 

the same notion of the infantry battalion, except that the upper bound factor has changed 

to 2.75 instead of 4, and the lower bound factor has changed to 1.25 instead of 2 as seen 

in the equations below. This was done because the Armor battalion requires relatively less 

manpower than the infantry battalion. 

1.25 *E7 <= E6 <=2.75*E7 

1.25 *E6 <= E5 <=2.75*E6 

1.25 *E5 <= E4 <=2.75*E5 

1.25 *E4 <= E3 <=2.75*E4 

1.25 *E3 <= E2 <=2.75*E3 
El <=2.75*E2 
01 <= 02 
02 <= 03 


In conclusion, these two models demonstrate the computer-based tools that will 

be linked to the BDE DSS in order to enhance the decision-making process when 

creating and maintaining the BDE organizational structures. The purpose of the Armor 

battalion is to illustrate that the model could be more complicated if additional decision 

variables were added to meet the modified objective function (see Appendix D). 
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Furthermore in the last ehapter, we will suggest a few points regarding modeling that will 
help to improve this eapability in the BDF DSS. 

Meanwhile, the last part in designing a DSS is the DSS user interfaee that allows 
the user to aeeess the internal eomponents of the DSS in a relatively easy fashion and 
without having to know speoifieally how everything is put together or how it works 
together. The last set of appendixes in this researeh will briefly deseribe eaeh part of the 
user interfaee prototypes whieh are supported with figures. The appendixes will illustrate 
the following; 

1. Appendix E: Program eontrol diagrams 

2. Appendix F: Prototype of input/output forms 

3. Appendix G: Prototype of queries 

4. Appendix H; Prototype of reports 

5. Appendix I: Prototype of analysis forms 

6. Appendix J: Brief Users’ Manual 
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V. THE USER INTERFACES 


A, INTRODUCTION 

The user interface, the last component in designing a DSS, is one of the most 
important parts of any program because it determines how easily you can make the 
program do what you want. A powerful program with a poorly designed user interface 
has little value. Also, graphical user interfaces (GUIs) that use windows, icons, and pop¬ 
up menus have become standard on today’s computer systems. [Ref 9] 

Therefore and as proof of concept, we will demonstrate in this chapter a specific 
use case scenario, namely, building a new unit and how the DSS user would evaluate it 
through the BDF_DSS user interface capabilities. In this case study, we will presume that 
the BDF wants to establish a new infantry battalion besides the two existing ones they 
have right now (101 and 103). Additionally, this new unit has an initial structure depicted 
on paper and has not been entered in the BDF_DSS yet. Basically, we will tackle the 
BDF DSS user interface functionalities into two stages: 

1. Data entry and editing stage 

2. Analysis and rebuilding proposals stage. 

B. DATA ENTRY AND EDITING STAGE 

The user would first enter the preliminary structure of the new unit in the 
BDF DSS and give it a unique id number to be referred to later, as shown in Figure 6 
below. 



Figure 6. “Add new unit” Form 
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By clicking on the “Save Reeord” button, the user has entered a new proposed 
infantry battalion in the system. Then, to attach the manpower resources to that unit, the 
user needs to return to the “Forms” menu and elick on the “Add new jobs to a unit” 
button that will popup the manpower data entry form as shown in Figure 7 below. As 
long as the manpower required for this unit are in the BDF job dictionary (job table), the 
user will insert the unit manpower records using this form; otherwise the user needs to 
insert those jobs first into the job table. Similarly, to attaeh the vehicles and weapons 
resources to that unit, the user needs to seleet “Add new vehicles to a unit” or “Add new 
weapons to a unit” in the “Forms” main menu, and follow the same proeedure as for 
attaching unit manpower. 



Figure 7. “Add new jobs to a unit” Form 


Having entered the new unit structure in the BDF DSS, the user now can edit all 
records related to that unit via the “Modify” part of “Forms” main menu. For instanee, 
the user can make neeessary corrections in unit 905 vehicles by clicking on the “Modify 
vehicles on a unit” button as shown on Figure 8 below. To speed up this process, the user 
must filter unit 905 vehicles from other unit vehieles by using the “Filter by form” ieon 
which is the third one in the tool bar list. 
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Figure 8. “Modify vehicles in a unit” Form 


Alternatively, if the BDF DSS already has a similar unit type, the user can utilize 
the built-in system tool called “Copy any unit as a proposed unit” to rapidly enter the new 
unit 905 and its resources in the BDF DSS. This capability as shown in Figure 9 below is 
found in the Analysis main menu which will be widely used in analyzing proposals that 
requires generating unit scenarios function. After this step, the user can make small 
modifications to unit 905 resources to match the initial structure. 


“vpe a question for help ^ 


^xj 


Q Microsoft Access 


Exit 2 WindowHtde S WinowUnhide 


Select the Unit ID you wish to copy [Toi 2] 

Enter a new Unit ID for that unit |905| 

Copy I Cancel | 

Figure 9. “Copy any unit as a proposed unit” Form 


41 


































c 


ANALYSIS AND REBUILDING PROPOSALS STAGE 

At this stage, the user ean eompare the 905 unit structure to similar existing ones 


by viewing a query available in the “Queries” main menu as shown in Figure 10 below. 
However, this figure depicts unit statistics only and does not give explanations about 
dilFerences among similar unit type structures. Therefore, other queries can be used to 
view unit resource differences as shown in Figure 11 below. 
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‘Query units” Form 



Datasheet View 

Figure 11. “Compare two units by jobs” Crosstab Query 
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Moreover, the user can see the impact of unit 905 on the overall BDF existing 
units (101, 102, and 103 in this case) as illustrated in Figure 12 below. This screen 
utilizes the chart capability in the BDF DSS application that shows only the unit cost 
drivers such as unit annual salary, vehicle maintenance cost for this year, and vehicle total 
cost for each unit. However, the user can use other visualization tool like pivot tables to 
see numbers and grand totals among those units as shown in Figure 13 below. The chart 
and pivot tables’ tools are available in the application forms and queries which allow the 
user to drill, slice and dice, and change displays in the desired measures and dimensions. 
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UnitlD2 ’ 


Figure 12. 3-D Chart of Unit 905 and All Other Existing BDF Units 
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Figure 13. Pivot Table of Unit 905 and All Other Existing BDE Units in Percentages 
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Most of the time, the user gets feedback from BDF officials about the manpower 
budget constraint. Hypothetically, we will presume that the HR budget constraint of 
building unit 905 is $6,000,000 (at least 20% less than the annual salary of unit 101 and 
103 infantry battalions). Thus, the user can use the built-in HR optimization models to 
figure out the best rank distribution within this constraint and others as described in 
earlier chapter. Thus, as shown in Figure 14 below, the user can select the Optimization 
model submenu from the “Analysis” main menu and then click on the “Infantry 
Battalion” icon that matches the unit 905 type and start to play different scenarios. As 
shown on Figure 15 below, we assume that the user has run different scenarios and 
“what-if ’ questions and found that solution as the most reasonable option to the problem 
at hand. 


ms 
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Exit 3 WindowHide 3 WinowUnhide 
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Armor Battalion.xls 


Return to Analysis | 


Figure 14. Optimization Models Submenu 



Figure 15. MS Excel spreadsheet of the Infantry Battalion HR Model 
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After assuring that this is the best solution and the decision variables reflect 
reality for the required structure, the user can rebuild the unit 905 based on the values that 
will represent unit 905 manpower requirements. Ultimately, the user will see that all 
constraints set in the previous model are verified automatically by the system as depicted 
in Figure 16 below. Additionally, the user can view more details on unit 905 as seen in 
Figure 17 below. 



Figure 16. “View proposed units” Form 


45 










































































^ Mf>re detais 


Remember! ...These calculated fields are based on # of jobs which symbolizes 

BUDGETED cost 

Allowances [ 

_I I 

_iizzmEHj 

_I I ■ I 

_II I 


Projected budgeted salaries for each rank in this unit 


Rank 

Base saary 

Sum Of 
Number 
Of Jobs 

Budgeted 

annua 

saa^ 

Next yea' 
budgeted 
annua saa^ 

Next 2 years 
budgeted 
annua' saa'v 

Next 3 years 
budgeted 
annua saa'v 

Next 4 years 
budgeted 
annua! saary 

Next 5 yea's 
budgeted 
annua saa'v 


> 

COL 

S-4,500.00 


S54,000.00 

556.700.00 

559,535.00 

562,511.75 

565,637.34 

568.919.20 



LTC 

S4.000.00 

6 

5288.000.00 

5302.400.00 

5317,520.00 

5333,396.00 

5350.065.80 

5367,569.09 



MAJ 

S3.500.00 

14 

5588.000.00 

5617.400.00 

5648.270.00 

5680,683.50 

5714,717.68 

5750.453.56 



CAPT 

S3.000.00 

3 

5108.000.00 

5113.400.00 

5119,070.00 

5125,023.50 

5131,274.68 

5137,838.41 



Lt 

S2.500.00 

3 

590.000.00 

594.500.00 

599,225.00 

5104,186.25 

5109,395.56 

5114,865.34 



2ndLt 

52,000.00 

3 

572.000.00 

575.600.00 

579,380.00 

583,349.00 

587.516.45 

591,892.27 



War 

51,500.00 

7 

5126.000.00 

5132.300.00 

5138.915.00 

5145,860.75 

5153,153.79 

5160,811.48 



2ndWar 

51,300.00 

14 

5218.400.00 

5229,320.00 

5240,786.00 

5252,825.30 

5265,466.57 

5278,739.89 



SGTM 

51,100.00 

28 

5369.600.00 

5388.080.00 

5407,484.00 

5427,858.20 

5449,251.11 

5471.713.67 



SGT 

S900.00 

56 

5604.800.00 

5635.040.00 

5666,792.00 

5700,131.60 

5735,138.18 

5771,895.09 



Cpl 

S700.00 

112 

5940.800.00 

5937.840.00 

;l,037,232.00 

:i,089,093.60 

:l, 143,548.28 

:l.200,725.69 



L.CpI 

S500.00 

225 

:l.350.000.00 

:1,417,500.00 

;i,488,375.00 

:l.562,793.75 

:l,640.933.44 

;i,722,980.11 


Record: li I 

U 

1 Mm 

► *l of 14 



Figure 17. “More details” Form 


In conclusion, this chapter has briefly illustrated the BDF DSS user interfaces 
through a case study that requires building a new infantry battalion (905). Flowever, the 
last group of the appendixes show more examples of user interfaces as well as provide a 
brief users’ manual. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. SUMMARY 

This thesis designed and developed a DSS prototype that integrated relational 
database with optimization models to analyze organizational problems arising in the 
BDF. Initially, we deseribed the eurrent proeesses for maintaining the BDF organizational 
struetures in order to justify the BDF needs for a eomputer-based system in this area. In 
addition, the signifieant parameters that must be taken into eonsideration while 
proeessing the BDF struetures were identified in order to measure a strueture’s validity 
and feasibility. 

The thesis then presented the DSS design phase; whieh involved the development 
of a database applieation. The data element of the DSS was diseussed in three stages: the 
eoneeptual data model, the physieal design, and the proeess design. The required system 
eapabilities were ineorporated in the system design phase: the visualization tools and 
analytieal models. 

Next, the researeh introduced two examples of optimization models that are 
linked to the BDF DSS database. The performance metrics discussed in an earlier 
chapter were embedded in the models’ design to reflect the supportability of the system. 
Generally, the two examples were an attempt to satisfy the BDF requirements in 
articulating resource-planning problems to find the best options among the many 
scenarios. 

Finally, to complete the creation of the required BDF DSS, the last part of the 
thesis was dedicated to the user interfaces which are shown in the related appendixes. 
Furthermore, a brief user’s manual was provided at the end of the research to help real 
decision-makers use the system. 

B, BDF DSS BENEFITS 

As a result of this work, BDF can obtain several benefits when implementing the 
DSS tool prototyped in this research: 
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1. DSS users can easily analyze the effectiveness of BDF organizational structures 
with less effort and in a shorter time. With this DSS tool, users can approximately 
achieve 50% time savings required to manipulate the BDF organizational 
structures. 

2. The DSS can help users to produce evidence in support of a decision confirmation 
for a proposed BDF organizational structure. In other words, these decisions are 
based upon data and analysis instead of intuition or heuristic. 

3. The DSS users can produce a wider range of unit structure options and then select 
the most appealing ones to be presented. 

4. As they gain experience with the DSS, DSS users can develop new approaches 
when thinking about a problem area or decision context. In other words, the DSS 
users can improve their ability to tackle complex unit structures as time passes. 

5. Last but not least, the suggested decision system allows for careful, analytical 
financial planning. This means that the DSS users can easily obtain the projected 
costs of the BDF structures, which gives the users, and the BDF, a robust 
resource-planning tool. 

C. RECOMMENDATIONS 

A future study of this topic is germane to the BDF. The proposed BDF DSS is 
sufficient as a first step but it is not fully operational as was discussed earlier. The 
recommendations for a future research in this field are summarized as follows: 

• The development cycle of this DSS must never stop whenever a system update is 
needed to meet the added objectives. 

• Beside the manpower, vehicles, and weapons resources, the DSS must include all 
of the tangible and non-tangible resources needed to run a unit structure in order 
to give the decision-maker a complete picture of the unit total estimated cost. For 
instance, tangible resources could be other operational equipment that is not 
included in the system (i.e. communication equipment and weapon ammunitions). 
Also, non-tangible resources could be manpower-related costs such as training 
costs, health care costs, etc; or costs related to the unit itself such as a unit’s 
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military exercise costs and unit service costs such as electricity, water and so 
forth. 

• The optimization models developed in this system can be further remodeled with 
more valid assumptions to accurately reflect reality. 

• In addition, the optimization models in this research were exclusively considering 
the HR basic salary costs. Thus, other HR cost drivers such as allowances can be 
embedded in the model to achieve HR cost precision. 

• A more robust database engine must be considered when building such a system 
to speed up the application processing time and to accommodate further data 
expansion and features. For example, Microsoft SQL Server or Oracle databases 
can house and process larger data than MS Access™ does. 

• With regard to information security issue, this system can easily be transformed to 
a Web-based system using the Microsoft Data Access Page tool (DAP) in order to 
allow decision-makers to remotely present their models and data from anywhere. 

• Finally, the optimization model in this system can be extended to include other 
model types such as forecasting model. Using time series or regression methods, 
for instance, users can predict BDF manpower end strength requirements over the 
next 3, 5, 10 years. This type of model could then feed the related optimization 
model. 

This thesis has shown a useful integration of database and optimization 
technology that can potentially help solve real problems in the BDF. By combining 
optimization models in a transparent way with standard database management tools, a 
simple yet effective decision support system has been developed to evaluate and compare 
BDF organizational unit structures. The benefits of this system underscore the value of 
good decision support, namely more decision alternatives can be evaluated in a shorter 
amount of time. 
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APPENDIX A: ENTITY RELATIONSHIP DIAGRAMS OF BDF DSS 


Visible %steiTB CoipcnalionrouCATlONAl/IRAMNGVeisicin 

Primaiy Levd 



Figure 18. Entity Relationship Diagram of the Database Model - Primary Key Level 
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Visible Systems CoiporationEDUCAHONAI/TRAINWG Version 
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Figure 19. Entity Relationship Diagram of the Database Model - Attribute Level 
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APPENDIX B: DATABASE SCHEMA OF BDF DSS 


1, RELATIONAL MODEL 

Jobs ( JobType , Description, Service, Category) 

Manpower (UnitID FK. JobType FK . Rank FK. NumberofJobs, 
NumberofOccupiedJobs) 

Salaries ( Rank , RankLevel, BasicSalary, YearlyIncrementRate, 

TransportationAllowance, SocialAllowance, LivingAllowance/Y, 
ClothingAllowance/Y) 

Units (UnitID , ProposedUnit, UnitType, UnitSize, BaseOccupiedJobs, Manpowersize, 

OfFiserSize, EnlistedSize, Annualsalary, OPS, ADMIN, TECH, VehicleTotalCost, 
VehicleMaintCostThisY, WeaponTotalCost, WeaponMaintCostThisY, 
TransportationAllowance, SocialAllowance, EivingAllowance/Y, 
ClothingAllowance/Y, OfficersSalary, EnlistedCivilianSalary) 

Units_Vehides (VehiclcType FK, UnitID FK , VehiclesQuantity) 

Units_Weapons (WeaponType FK, UnitID FK . WeaponsQuantity) 

Vehicles ( VehiclcType , InitialCost, ManufacturingCountry, ProductionYear, 
MaintenanccRate, Description) 

Weapons (WeaponType , InitialCost, ManufacturingCountry, ProductionYear, 
MaintenanccRate, Description) 
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2. GENERATED DATABASE SCHEMA 


CREATE TABEE Jobs 

( 

Job Type 
Description 
Service 
Category 

); 


CHAR(20) NOT NULL, 
CHAR(400), 

CHAR(20), 

CHAR(20) NOT NULL 


CREATE TABLE Manpower 

( 

UnitID 
Job Type 
Rank 

NumberofJobs 

NumberofOccupiedJobs 

); 


INTEGER NOT NULL, 
CHAR(20) NOT NULL, 
CHAR(20) NOT NULL, 
CHAR(20), 

INTEGER, 


CREATE TABLE Salaries 

( 

Rank 

RankLevel 

Basic Salary 

YearlyIncrementRate 

TransportationAllowance 

SocialAllowance 

LivingAllowanceAf 

ClothingAllowanceAf 

); 

CREATE TABLE Units 

( 

UnitID 

ProposedUnit 

UnitType 

UnitSize 

BaseOccupiedJobs 

ManpowerSize 

OffiserSize 

EnlistedSize 

Annualsalary 

OPS 

ADMIN 

TECH 

VehicleTotalCost 


CHAR(20) NOT NULL, 
CHAR(IO) NOT NULL, 
CHAR(20) NOT NULL, 
NUMBER NOT NULL, 
MONEY, 

MONEY, 

MONEY, 

MONEY 


INTEGER NOT NULL, 
BIT, 

INTEGER NOT NULL, 
CHAR(50) NOT NULL, 
BIT, 

INTEGER, 

INTEGER, 

INTEGER, 

CHAR(20), 

INTEGER, 

INTEGER, 

INTEGER, 

MONEY, 
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VehicleMaintCostThisY 

MONEY, 

WeaponTotalCost 

MONEY, 

WeaponMaintCostThisY 

MONEY, 

TransportationAllowance 

MONEY, 

SocialAllowance 

MONEY, 

LivingAllowanceAf 

MONEY, 

ClothingAllowanceAf 

MONEY, 

OfficersSalary 

MONEY, 

EnlistedCivilianSalary 

MONEY 


CREATE TABLE Units Vehicles 

( 

VehicleType CHAR(50) NOT NULL, 

UnitID INTEGER NOT NULL, 

VehiclesQuantity INTEGER 

); 


CREATE TABLE Units Weapons 


( 

WeaponType 

UnitID 

WeaponsQuantity 

); 

CREATE TABLE Vehicles 

( 

VehicleType 

InitialCost 

ManufacturingCountry 

ProductionYear 

MaintenanceRate 

Description 

); 

CREATE TABLE Weapons 

( 

WeaponType 

InitialCost 

ManufacturingCountry 

ProductionYear 

MaintenanceRate 

Description 

); 


CHAR(50) NOT NULL, 
INTEGER NOT NULL, 
INTEGER 


CHAR(50) NOT NULL, 
CHAR(20) NOT NULL, 
CHAR(20) NOT NULL, 
INTEGER NOT NULL, 
NUMBER NOT NULL, 
CHAR(400) 


CHAR(50) NOT NULL, 
CHAR(20) NOT NULL, 
CHAR(20) NOT NULL, 
INTEGER NOT NULL, 
NUMBER NOT NULL, 
CHAR(400) 
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CREATE UNIQUE INDEX PKJobs ON Jobs ( JobType ASC ); 

CREATE UNIQUE INDEX PKManpower ON Manpower (UnitID ASC, JobType ASC, Rank ASC ); 
CREATE UNIQUE INDEX PKSalaries ON Salaries ( Rank ASC ); 

CREATE UNIQUE INDEX PKUnits ON Units ( UnitID ASC ); 

CREATE UNIQUE INDEX PKUnits_Vehicles ON Units_Vehicles ( VehicleType ASC, UnitID ASC ); 
CREATE UNIQUE INDEX PKUnits_Weapons ON Units_Weapons ( WeaponType ASC, UnitID ASC ); 
CREATE UNIQUE INDEX PKVehicles ON Vehicles ( VehicleType ASC ); 

CREATE UNIQUE INDEX PKWeapons ON Weapons ( WeaponType ASC ); 

ALTER TABLE Jobs ADD 

CONSTRAINT PKCJobsOOOO PRIMARY KEY ( JobType ); 

ALTER TABLE Manpower ADD 

CONSTRAINT PKC_Manpower0004 PRIMARY KEY (UnitID, JobType, Rank); 

ALTER TABLE Salaries ADD 

CONSTRAINT PKC_Salaries0005 PRIMARY KEY ( Rank); 

ALTER TABLE Units ADD 

CONSTRAINT PKC_Units0006 PRIMARY KEY (UnitID ); 

ALTER TABLE Units_Vehicles ADD 

CONSTRAINT PKC_Units_Vehicles0009 PRIMARY KEY ( VehicleType, UnitID ); 

ALTER TABLE Units Weapons ADD 

CONSTRAINT PKC_Units_WeaponsOOOC PRIMARY KEY (WeaponType, UnitID ); 

ALTER TABLE Vehicles ADD 

CONSTRAINT PKC_VehiclesOOOD PRIMARY KEY ( VehicleType ); 

ALTER TABLE Weapons ADD 

CONSTRAINT PKC_WeaponsOOOE PRIMARY KEY (WeaponType ); 

ALTER TABLE Manpower ADD 

CONSTRAINT FKC_BelongsOOO 1 FOREIGN KEY ( Rank) REFERENCES Salaries; 

ALTER TABLE Manpower ADD 

CONSTRAINT FKC_Belongs0002 FOREIGN KEY ( JobType ) REFERENCES Jobs; 

ALTER TABLE Manpower ADD 

CONSTRAINT FKC_Contains0003 FOREIGN KEY ( UnitID ) REFERENCES Units; 

ALTER TABLE Units Vehicles ADD 
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CONSTRAINT FKC_Is_Allocated_To0007 FOREIGN KEY ( VehicleType ) REFERENCES 
Vehicles; 

ALTER TABLE Units_Vehicles ADD 

CONSTRAINT FKC_Has0008 FOREIGN KEY ( UnitID ) REFERENCES Units; 

ALTER TABLE Units Weapons ADD 

CONSTRAINT FKC_Is_allocated_ToOOOA FOREIGN KEY ( WeaponType ) REFERENCES Weapons; 
ALTER TABLE Units Weapons ADD 

CONSTRAINT FKC_Has000B FOREIGN KEY ( UnitID ) REFERENCES Units; 
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APPENDIX C: RELATIONAL DATABASE DESIGN OF BDF DSS 

FROM MS ACCESSTM 


1. RELATIONAL STRUCTURE DIAGRAM 


Q Microsoft Access - [Relatkmships] 


File Edit Vie* Relatonships Tools Window Help 


iSv T Is! X 0 i- [ 3 , 


WeeponType 

IniOalCost 

ManufacturingCountry 

ProductonYear 

MamtenanceRate 

bescription 





UniflD 

WeaponType 

VeaponsQuantity 



RankLevel 

BasicSalary 

YearlyInaementRate 

TransportatonAllowance 

SoaalAllowance 

LivingAlowance/Y 

ClothingAllowance/Y 


ums 

JobType 
Railt 

NumberOfJobs 
NumberOfOccupiedJobs 


UnifiD 

ProposedUnit 

LinitType 

UnitSize 

BaseOccupiedJobs 

ManpowerSize 

OflicerSize 

EnlistedSize 

Annualsalary 

OPS 

ADMIN 

TECH 

VehideTotalCost 

VehideMaintCostThlsY 

WeaponTotalCost 

WeaponMaintCostThisY 

TransportabpnAllowance 

SooalAllowance 

LivingAllowance/Y 

ClothingAllowance/Y 

OfficersSalary 

EnlistedCivilianSalary 



■ype a question for help 




InitalCost 

ManufacturingCounpy 

ProductonYear 

MamtenanceRate 

Descripton 


Figure 20. MS Access™ Relational Structure Diagram of BDF DSS 
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2. RELATIONSHIPS PROPERTIES 


JobsManpower 


Jobs 

1 oo 

Manpower 

JobType 

JobType 



Attributes: Enforced, Cascade Updates, Cascade Deletes 

RelationshipType: One-To-Many 

SalariesManpower 


Salaries 

1 oo 

Manpower 

Rank 

Rank 



Attributes: Enforced, Cascade Updates, Cascade Deletes 

RelationshipType: One-To-Many 

UnitsManpower 


Units 

1 oo 

Manpower 

UnitID 

UnitID 



Attributes: Enforced, Cascade Updates, Cascade Deletes 

RelationshipType: One-To-Many 

UnitsUnits_Vehicles 


Units 

1 OO 

Units_Vehicles 

UnitID 

UnitID 



Attributes: Enforced, Cascade Updates, Cascade Deletes 

RelationshipType: One-To-Many 

UnitsUnits_Weapons 


Units 

1 OO 

Units_Weapons 

UnitID 

UnitID 



Attributes: Enforced, Cascade Updates, Cascade Deletes 

RelationshipType: One-To-Many 

VehiclesUnits_Vehicles 


Vehicles 

1 oo 

Units_Vehicles 

VehicleType 

VehicleType 



Attributes: Enforced, Cascade Updates, Cascade Deletes 

RelationshipType: One-To-Many 


WeaponsUnits_Weapons 


Weapons 

1 oo 

Units_Weapons 

WeaponType 

WeaponType 



Attributes: Enforced, Cascade Updates, Cascade Deletes 

RelationshipType: One-To-Many 
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APPENDIX D: OPTIMIZATION MODELS 


1. INFANTRY BATTALION 



Figure 21. Mathematical Model of the Infantry Battalion 
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Figure 22. Implemented Model of the Infantry Battalion 
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Microsoft Excel 10.0 Answer Report 
Worksheet: [Infantry Battalion.xls]Sheet1 
Report Created: 4/19/2003 10:43:46 PM 


Target Cell (Max) 


Cell 

Name 

Original Value 

Final Value 


$Q$54 

Optimum # of each rank Total 

0 

728 



Adjustable Cells 

Cell 

Name 

Original Value 

Final Value 

$C$54 

Optimum # of each rank COL (06) 

0 

1 

$D$54 

Optimum # of each rank LTC (05) 

0 

6 

$E$54 

Optimum # of each rank MAJ (04) 

0 

14 

$F$54 

Optimum # of each rank CAPT (03) 

0 

3 

$G$54 

Optimum # of each rank LT (02) 

0 

3 

$H$54 

Optimum # of each rank 2ndLT (01) 

0 

3 

$l$54 

Optimum # of each rank WAR (E7) 

0 

7 

$J$54 

Optimum # of each rank 2ndWAR (E6) 

0 

14 

$K$54 

Optimum # of each rank SGTM (E5) 

0 

28 

$L$54 

Optimum # of each rank SGT (E4) 

0 

56 

$M$54 

Optimum # of each rank CPL (E3) 

0 

112 

$N$54 

Optimum # of each rank LCPL (E2) 

0 

225 

$0$54 

Optimum # of each rank PTE (E1) 

0 

223 

$P$54 

Optimum # of each rank CIV 

0 

33 


Constraints 

Cell 

Name 

Cell Value 

Formula 

Status 

Slack 

$0$44 

Optimum annual salary for officers (OS) Optimum solutions 

$1,200,000.00 

$0$44<=$l$44 

Binding 

0 

$0$45 

Optimum annual salary for enlisted (ES) Optimum solutions 

$4,680,000.00 

$0$45<=$l$45 

Binding 

0 

$0$46 

Optimum annual salary for civilian (CS) Optimum solutions 

$118,800.00 

$0$46<=$l$46 

Not Binding 

1200 

$K$54 

Optimum # of each rank SGTM (E5) 

28 

$K$54<=$J$35*$J$54 

Not Binding 

28 

$0$54 

Optimum # of each rank PTE (El) 

223 

$0$54<=$J$35*$N$54 

Not Binding 

677 

$M$54 

Optimum # of each rank CPL (E3) 

112 

$M$54<=$J$35*$L$54 

Not Binding 

112 

$L$54 

Optimum # of each rank SGT (E4) 

56 

$L$54>=$J$36*$K$54 

Binding 

0 

$J$54 

Optimum # of each rank 2ndWAR (E6) 

14 

$J$54>=$J$36*$I$54 

Binding 

0 

$N$54 

Optimum # of each rank LCPL (E2) 

225 

$N$54<=$J$35*$M$54 

Not Binding 

223 

$M$54 

Optimum # of each rank CPL (E3) 

112 

$M$54>=$J$36*$L$54 

Binding 

0 

$L$54 

Optimum # of each rank SGT (E4) 

56 

$L$54<=$J$35*$K$54 

Not Binding 

56 

$0$49 

Optimum # of enlisted & civ (ECM) Optimum solutions 

698.00 

$0$49<=$l$49 

Not Binding 

0.88 

$J$54 

Optimum # of each rank 2ndWAR (E6) 

14 

$J$54<=$J$35*$I$54 

Not Binding 

14 

$K$54 

Optimum # of each rank SGTM (E5) 

28 

$K$54>=$J$36*$J$54 

Binding 

0 


Annual salary per each rank Total 

$5,998,800.0 

$Q$55<=$D$35 

Not Binding 

1200 

$0$48 

Optimum # of officers (OM) Optimum solutions 

30.00 

$0$48>=$l$48 

Not Binding 


$H$54 

Optimum # of each rank 2ndLT (01) 

3 

$H$54<=$G$54 

Binding 

0 

$N$54 

Optimum # of each rank LCPL (E2) 

225 

$N$54>=$J$36*$M$54 

Not Binding 

1 

$G$54 

Optimum # of each rank LT (02) 

3 

$G$54<=$F$54 

Binding 

0 

$C$54 

Optimum # of each rank COL (06) 

1 

$C$54=$D$38 

Not Binding 

0 

$E$54 

Optimum # of each rank MAJ (04) 

14 

$E$54=$D$40 

Not Binding 

0 

$D$54 

Optimum # of each rank LTC (05) 

6 

$D$54=$D$39 

Not Binding 

0 

$C$54 

Optimum # of each rank COL (06) 

1 

$C$54>=0 

Not Binding 

1 

$D$54 

Optimum # of each rank LTC (05) 

6 

$D$54>=0 

Not Binding 

6 

$E$54 

Optimum # of each rank MAJ (04) 

14 

$E$54>=0 

Not Binding 

14 

$F$54 

Optimum # of each rank CAPT (03) 

3 

$F$54>=0 

Not Binding 

3 

$G$54 

Optimum # of each rank LT (02) 

3 

$G$54>=0 

Not Binding 

3 

$H$54 

Optimum # of each rank 2ndLT (01) 

3 

$H$54>=0 

Not Binding 

3 

$l$54 

Optimum # of each rank WAR (E7) 

7 

$l$54>=0 

Not Binding 

7 

$J$54 

Optimum # of each rank 2ndWAR (E6) 

14 

$J$54>=0 

Not Binding 

14 

$K$54 

Optimum # of each rank SGTM (E5) 

28 

$K$54>=0 

Not Binding 

28 

$L$54 

Optimum # of each rank SGT (E4) 

56 

$L$54>=0 

Not Binding 

56 

$M$54 

Optimum # of each rank CPL (E3) 

112 

$M$54>=0 

Not Binding 

112 

$N$54 

Optimum # of each rank LCPL (E2) 

225 

$N$54>=0 

Not Binding 

225 

$0$54 

Optimum # of each rank PTE (El) 

223 

$O$54>=0 

Not Binding 

223 

$P$54 

Optimum # of each rank CIV 

33 

$P$54>=0 

Not Binding 

33 

$l$54 

Optimum # of each rank WAR (E7) 

7 

$I$54=$D$41 

Binding 

0 

$C$54 

Optimum # of each rank COL (06) 

1 

$C$54=integer 

Binding 

0 

$D$54 

Optimum # of each rank LTC (05) 

6 

$D$54=integer 

Binding 

0 

$E$54 

Optimum # of each rank MAJ (04) 

14 

$E$54=integer 

Binding 

0 

$F$54 

Optimum # of each rank CAPT (03) 

3 

$F$54=integer 

Binding 

0 

$G$54 

Optimum # of each rank LT (02) 

3 

$G$54=integer 

Binding 

0 

$H$54 

Optimum # of each rank 2ndLT (01) 

3 

$H$54=integer 

Binding 

0 

$l$54 

Optimum # of each rank WAR (E7) 

7 

$l$54=integer 

Binding 


$J$54 

Optimum # of each rank 2ndWAR (E6) 

14 

$J$54=integer 

Binding 

0 

$K$54 

Optimum # of each rank SGTM (E5) 

28 

$K$54=integer 

Binding 

0 

$L$54 

Optimum # of each rank SGT (E4) 

56 

$L$54=integer 

Binding 

0 

$M$54 

Optimum # of each rank CPL (E3) 

112 

$M$54=integer 

Binding 

0 

$N$54 

Optimum # of each rank LCPL (E2) 

225 

$N$54=integer 

Binding 

0 

$0$54 

Optimum # of each rank PTE (El) 

223 

$0$54=integer 

Binding 

0 


Optimum # of each rank CIV 

33 

$P$54=integer 

Binding 

0 


Table 1. Infantry Battalion Answer Report 
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Figure 23. Mathematical Model of the Armor Battalion 
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Figure 24. Implemented Model of the Armor Battalion 
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Microsoft Excel 10.0 Answer Report 
Worksheet; [Armor Battalion.xls]Sheet1 
Report Created: 4/20/2003 1:47:42 AM 


Target Cell (Max) 

Cell 

Name 

Original Value 
__ 

Final Value 

$Q$58 

Total Total 


542 


Adjustable Cells 

Cell 

Name 

Original Value 

Final Value 

$C$55 

Optimal OPS COL (06) 

0 

1 

$D$55 

Optimal OPS LTC (05) 

0 

5 

$E$55 

Optimal OPS MAJ (04) 

0 

8 

$F$55 

Optimal OPS CAPT (03) 

0 

7 

$G$55 

Optimal OPS LT (02) 

0 

7 

$H$55 

Optimal OPS 2ndLT (01) 

0 

7 

$l$55 

Optimal OPS WAR (E7) 

0 

6 

$J$55 

Optimal OPS 2ndWAR (E6) 

0 

0 

$K$55 

Optimal OPS SGTM (E5) 

0 

0 

$L$55 

Optimal OPS SGT(E4) 

0 

16 

$M$55 

Optimal OPS CPL (E3) 

0 

43 

$N$55 

Optimal OPS LCPL (E2) 

0 

107 

$0$55 

Optimal OPS PTE (El) 

0 

196 

$P$55 

Optimal OPS CIV 

0 

8 

$C$56 

Optimal ADM COL (06) 

0 

0 

$D$56 

Optima! ADM LTC (05) 

0 

1 

$E$56 

Optimal ADM MAJ (04) 

0 

1 

$F$56 

Optimal ADM CAPT (03) 

0 

0 

$G$56 

Optimal ADM LT (02) 

0 

0 

$H$56 

Optimal ADM 2ndLT (01) 

0 

0 

$l$56 

Optimal ADM WAR (E7) 

0 

0 

$J$56 

Optimal ADM 2ndWAR (E6) 

0 

0 

$K$56 

Optimal ADM SGTM (E5) 

0 

0 

$L$56 

Optimal ADM SGT (E4) 

0 

0 

$M$56 

Optimal ADM CPL (E3) 

0 

1 

$N$56 

Optimal ADM LCPL (E2) 

0 

0 

$0$56 

Optima! ADM PTE (El) 

0 

33 

$P$56 

Optimal ADM CIV 

0 

10 

$C$57 

Optimal TECH COL (06) 

0 

0 

$D$57 

Optimal TECH LTC (05) 

0 

0 

$E$57 

Optimal TECH MAJ (04) 

0 

1 

$F$57 

Optimal TECH CAPT (03) 

0 

0 

$G$57 

Optimal TECH LT (02) 

0 

0 

$H$57 

Optimal TECH 2ndLT (01) 

0 

0 

$l$57 

Optimal TECH WAR (E7) 

0 

1 

$J$57 

Optimal TECH 2ndWAR (E6) 

0 

9 

$K$57 

Optimal TECH SGTM (E5) 

0 

12 

$L$57 

Optimal TECH SGT(E4) 

0 

0 

$M$57 

Optimal TECH CPL (E3) 

0 

0 

$N$57 

Optimal TECH LCPL (E2) 

0 

2 

$0$57 

Optimal TECH PTE (El) 

0 

48 

$P$57 

Optimal TECH CIV 

0 

12 


Constraints 

Cell 

Name 

Cell Value 

Formula 

Status 

Slack 

$Q$56 

Optimal ADM Total 

46 

$Q$56<=$0$42*$Q$58 

Not Binding 

8.2 

$O$50 

Optimum # of enlisted & civ (ECM) Operation 

504.00 

■ $0$56<=$l$56 

Not Binding 

5.48 

$Q$57 

Optimal TECH Total 

85 

$Q$57<=$0$43*$Q$58 

Not Binding 

1.72 

$0$45 

Optimum annual salary for officers (OS) Operation 

$1,392,000.00 

$0$45<=$l$45 

Not Binding 

47999.99998 

$0$46 

Optimum annual salary for enlisted (ES) Operation 

$2,950,800.00 

$0$46<=$l$46 

Not Binding 

19200 

$0$47 

Optimum annual salary for civilian (CS) Operation 

$108,000.00 

$0$47<=$l$47 

Not Binding 

4500 

$J$58 

Total 2ndWAR (E6) 

9 

$J$58>=$J$37*$I$58 

Not Binding 

0 

$N$58 

Total LCPL (E2) 

109 

$N$58<=$J$36*$M$58 

Not Binding 

12 

$L$58 

Total SGT(E4) 

16 

$L$58>=$J$37*$K$58 

Not Binding 

1 

$L$58 

Total SGT(E4) 

16 

$L$58<=$J$36*$K$58 

Not Binding 

17 

$J$58 

Total 2ndWAR (E6) 

9 

$J$58<=$J$36*$I$58 

Not Binding 

10.25 

$N$58 

Total LCPL (E2) 

109 

$N$58>=$J$37*$M$58 

Not Binding 

54 

$M$58 

Total CPL (E3) 

44 

$M$58<=$J$36*$L$58 

Binding 

0 

$K$58 

Total SGTM (E5) 

12 

$K$58>=$J$37*$J$58 

Not Binding 

1 

$0$49 

Optimum # of officers obtained (OM) Operation 

38.00 

$0$49>=$l$49 

Not Binding 

0.06 

$l$58 

Total WAR (E7) 

7 

$I$58=$D$42 

Not Binding 

0 

$K$58 

Total SGTM (E5) 

12 

$K$58<=$J$36*$J$58 

Not Binding 

12.75 

$Q$59 

Annual salary per each rank Total 

4,450,800 

$Q$59<=$D$36 

Not Binding 

49199.99998 

$H$58 

Total 2ndLT (01) 

7 

$H$58<=$G$58 

Binding 

0 

$G$58 

Total LT (02) 

7 

$G$58<=$F$58 

Binding 

0 

$M$58 

Total CPL (E3) 

44 

$M$58>=$J$37*$L$58 

Not Binding 

24 

$0$58 

Total PTE (El) 

277 

$0$58<=$J$36*$N$58 

Not Binding 

22.75 

$Q$55 

Optimal OPS Total 

411 

$Q$55>=$M$4r$Q$58 

Not Binding 

32 
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Constraints (Cont.) 


Cell 

Name 

Cell Value 

Formula 

Status 

Slack 

$Q$57 

Optimal TECH Total 

85 

$Q$57>=$M$43*$Q$58 

Not Binding 

58 

$Q$55 

Optimal OPS Total 

411 

$Q$55<=$0$41 *$Q$58 

Not Binding 

22.6 

$Q$56 

Optimal ADM Total 

46 

$Q$56>=$M$42*$Q$58 

Not Binding 

30 

$C$58 

Total COL (06) 

1 

$C$58=$D$39 

Not Binding 

0 

$C$55 

Optimal OPS COL (06) 

1 

$C$55>=0 

Not Binding 

1 

$D$55 

Optimal OPS LTC (05) 

5 

$D$55>=0 

Not Binding 

5 

$E$55 

Optimal OPS MAJ (04) 

8 

$E$55>=0 

Not Binding 

8 

$F$55 

Optimal OPS CAPT (03) 

7 

$F$55>=0 

Not Binding 

7 

$G$55 

Optimal OPS LT{02) 

7 

$G$55>=0 

Not Binding 

7 

$H$55 

Optimal OPS 2ndLT (01) 

7 

$H$55>=0 

Not Binding 

7 

$l$55 

Optimal OPS WAR (E7) 

6 

$l$55>=0 

Not Binding 

6 

$J$55 

Optimal OPS 2ndWAR {E6) 

0 

$J$55>=0 

Binding 

0 

$K$55 

Optimal OPS SGTM {E5) 

0 

$K$55>=0 

Binding 

0 

$L$55 

Optimal OPS SGT (E4) 

16 

$L$55>=0 

Not Binding 

16 

$M$55 

Optimal OPS CPL (E3) 

43 

$M$55>=0 

Not Binding 

43 

$N$55 

Optimal OPS LCPL (E2) 

107 

$N$55>=0 

Not Binding 

107 

$0$55 

Optimal OPS PTE (El) 

196 

$O$55>=0 

Not Binding 

196 

$P$55 

Optimal OPS CIV 

8 

$P$55>=0 

Not Binding 

8 

$C$56 

Optimal ADM COL (06) 

0 

$C$56>=0 

Binding 

0 

$D$56 

Optimal ADM LTC (05) 

1 

$D$56>=0 

Not Binding 

1 

$E$56 

Optimal ADM MAJ (04) 

1 

$E$56>=0 

Not Binding 

1 

$F$56 

Optimal ADM CAPT (03) 

0 

$F$56>=0 

Binding 

0 

$G$56 

Optimal ADM LT(02) 

0 

$G$56>=0 

Binding 

0 

$H$56 

Optimal ADM2ndLT (01) 

0 

$H$56>=0 

Binding 

0 

$l$56 

Optimal ADM WAR (E7) 

0 

$l$56>=0 

Binding 

0 

$J$56 

Optimal ADM 2ndWAR {E6) 

0 

$J$56>=0 

Binding 

0 

$K$56 

Optimal ADM SGTM (E5) 

0 

$K$56>=0 

Binding 

0 

$L$56 

Optimal ADM SGT (E4) 

0 

$L$56>=0 

Binding 

0 

$M$56 

Optimal ADM CPL (E3) 

1 

$M$56>=0 

Not Binding 

1 

$N$56 

Optimal ADM LCPL {E2) 

0 

$N$56>=0 

Binding 

0 

$0$56 

Optimal ADM PTE (E1) 

33 

$O$56>=0 

Not Binding 

33 

$P$56 

Optimal ADM CIV 

10 

$P$56>=0 

Not Binding 

10 

$C$57 

Optimal TECH COL (06) 

0 

$C$57>=0 

Binding 

0 

$D$57 

Optimal TECH LTC (05) 

0 

$D$57>=0 

Binding 

0 

$E$57 

Optimal TECH MAJ (04) 

1 

$E$57>=0 

Not Binding 

1 

$F$57 

Optimal TECH CAPT (03) 

0 

$F$57>=0 

Binding 

0 

$G$57 

Optimal TECH LT (02) 

0 

$G$57>=0 

Binding 

0 

$H$57 

Optimal TECH 2ndLT (01) 

0 

$H$57>=0 

Binding 

0 

$l$57 

Optimal TECH WAR (E7) 

1 

$l$57>=0 

Not Binding 

1 

$J$57 

Optimal TECH 2ndWAR (E6) 

9 

$J$57>=0 

Not Binding 

9 

$K$57 

Optimal TECH SGTM (E5) 

12 

$K$57>=0 

Not Binding 

12 

$L$57 

Optimal TECH SGT(E4) 

0 

$L$57>=0 

Binding 

0 

$M$57 

Optimal TECH CPL (E3) 

0 

$M$57>=0 

Binding 

0 

$N$57 

Optimal TECH LCPL (E2) 

2 

$N$57>=0 

Not Binding 

2 

$0$57 

Optimal TECH PTE (El) 

48 

$O$57>=0 

Not Binding 

48 

$P$57 

Optimal TECH CIV 

12 

$P$57>=0 

Not Binding 

12 

$D$55 

Optimal OPS LTC (05) 

5 

$D$55=$0$36 

Binding 

0 

$D$57 

Optimal TECH LTC (05) 

0 

$D$57=$Q$36 

Binding 

0 

$C$55 

Optimal OPS COL (06) 

1 

$C$55=$D$39 

Binding 

0 

$D$56 

Optimal ADM LTC (05) 

1 

$D$56=$P$36 

Binding 

0 

$E$55 

Optimal OPS MAJ (04) 

8 

$E$55=$0$37 

Binding 

0 

$E$56 

Optimal ADM MAJ (04) 

1 

$E$56=$P$37 

Not Binding 

0 

$E$57 

Optimal TECH MAJ (04) 

1 

$E$57=$Q$37 

Binding 

0 

$F$56 

Optimal ADM CAPT (03) 

0 

$F$56=$P$38 

Not Binding 

0 

$F$57 

Optimal TECH CAPT (03) 

0 

$F$57=$Q$38 

Not Binding 

0 

$G$56 

Optimal ADMLT (02) 

0 

$G$56=$P$39 

Binding 

0 

$G$57 

Optimal TECH LT (02) 

0 

$G$57=$Q$39 

Binding 

0 

$H$56 

Optimal ADM 2ndLT (01) 

0 

$H$56=$P$40 

Not Binding 

0 

$H$57 

Optimal TECH 2ndLT (01) 

0 

$H$57=$Q$40 

Binding 

0 

$C$55 

Optimal OPS COL (06) 

1 

$C$55=inteqer 

Binding 

0 

$D$55 

Optimal OPS LTC (05) 

5 

$D$55=inteqer 

Binding 

0 

$E$55 

Optimal OPS MAJ (04) 

8 

$E$55=inteqer 

Binding 

0 

$F$55 

Optimal OPS CAPT (03) 

7 

$F$55=inteqer 

Binding 

0 

$G$55 

Optimal OPS LT (02) 

7 

$G$55=inteqer 

Binding 

0 

$H$55 

Optimal OPS 2ndLT (01) 

7 

$H$55=integer 

Binding 

0 

$l$55 

Optimal OPS WAR (E7) 

6 

$l$55=inteqer 

Binding 

0 

$J$55 

Optimal OPS 2ndWAR (E6) 

0 

$J$55=inteqer 

Binding 

0 

$K$55 

Optimal OPS SGTM (E5) 

0 

$K$55=inteqer 

Binding 

0 

$L$55 

Optimal OPS SGT (E4) 

16 

$L$55=inteqer 

Binding 

0 

$M$55 

Optimal OPS CPL (E3) 

43 

$M$55=inteqer 

Binding 

0 

$N$55 

Optimal OPS LCPL (E2) 

107 

$N$55=integer 

Binding 

0 


Optimal OPS PTE (El) 

196 

$0$55=inteqer 

Binding 

0 

$P$55 

Optimal OPS CIV 

8 

$P$55=inteqer 

Binding 

0 

$C$56 

Optimal ADM COL (06) 

0 

$C$56=inteqer 

Binding 

0 

$D$56 

Optimal ADM LTC (05) 

1 

$D$56=inteqer 

Binding 

0 

$E$56 

Optimal ADM MAJ (04) 

1 

$E$56=inteqer 

Binding 

0 

$F$56 

Optimal ADM CAPT (03) 

0 

$F$56=inteqer 

Binding 

0 

$G$56 

Optimal ADM LT(02) 

0 

$G$56=inteqer 

Binding 

0 

$H$56 

Optimal ADM2ndLT (01) 

0 

$H$56=inteqer 

Binding 

0 

$l$56 

Optimal ADM WAR (E7) 

0 

$l$56=inteqer 

Binding 

0 

$J$56 

Optimal ADM 2ndWAR (E6) 

0 

$J$56=inteqer 

Binding 

0 

$K$56 

Optimal ADM SGTM (E5) 

0 

$K$56=inteqer 

Binding 

0 

$L$56 

Optimal ADM SGT (E4) 

0 

$L$56=inteqer 

Binding 

0 

$M$56 

Optimal ADM CPL (E3) 

1 

$M$56=inteqer 

Binding 

0 

$N$56 

Optimal ADM LCPL (E2) 

0 

$N$56=inteqer 

Binding 

0 

$0$56 

Optimal ADM PTE(E1) 

33 

$0$56=inteqer 

Binding 

0 

$P$56 

Optimal ADM CIV 

10 

$P$56=inteqer 

Binding 

0 

$C$57 

Optimal TECH COL (06) 

0 

$C$57=inteqer 

Binding 

0 

$D$57 

Optimal TECH LTC (05) 

0 

$D$57=inteqer 

Binding 

0 

$E$57 

Optimal TECH MAJ (04) 

1 

$E$57=integer 

Binding 

0 

$F$57 

Optimal TECH CAPT (03) 

0 

$F$57=inteqer 

Binding 

0 

$G$57 

Optimal TECH LT (02) 

0 

$G$57=inteqer 

Binding 

0 

$H$57 

Optimal TECH 2ndLT (01) 

0 

$H$57=inteqer 

Binding 

0 

$l$57 

Optimal TECH WAR (E7) 

1 

$l$57=inteqer 

Binding 

0 

$J$57 

Optimal TECH 2ndWAR (E6) 

9 

$J$57=inteqer 

Binding 

0 

$K$57 

Optimal TECH SGTM (E5) 

12 

$K$57=integer 

Binding 

0 

$L$57 

Optimal TECH SGT (E4) 

0 

$L$57=inteqer 

Binding 

0 

$M$57 

Optimal TECH CPL (E3) 

0 

$M$57=inteqer 

Binding 

0 

$N$57 

Optimal TECH LCPL (E2) 

2 

$N$57=inteqer 

Binding 

0 

$0$57 

Optimal TECH PTE (El) 

48 

$0$57=inteqer 

Binding 

0 

$P$57 

Optimal TECH CIV 

12 

$P$57=integer 

Binding 

0 
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APPENDIX E: PROGRAM CONTROL DIAGRAMS 


y Microsoft: Access 


Exit S WindowHide 3 WinowUnhide 



Figure 25. Main Menu Switehboard 


Type a question fo; iielp 
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Q Microsoft Acx^s 


^Xj 

Exit a WindowHide a WinowUnhide 'Type a question for help 



Figure 26. Forms Switchboard 
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Q Microsoft Access 


J^xJ 

Exit 3 WindowHide 3 WinowUnhide 'Type a question for help 



Figure 27. Queries Switchboard 
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Q Microsoft Access 


^2<J 

Exit 3 WindowHide 3 WinowUnhide Type a question for help 



Figure 28. Reports Switchboard 
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Figure 29. Analysis Switchboard 
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APPENDIX F: PROTOTYPE OF INPUT/OUTPUT FORMS 


1. INPUT FORMS 



Figure 30. “Add new unit” Form 



Figure 31. “Add new j ob” Form 
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Figure 32. “Add new ra nk with salary info” Form 


Microsoft Acx»ss 


H P- ^ li M ^ ^ 


^xj 

ype a question for help ■r 



Figure 33. “Add new vehicle” Form 
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Figure 34. “Add new weapon” Form 


IS Microsoft Access 


H 9- X % e, .. 



Figure 3 5. “Add new j obs to a unit” Form 
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Q Microsoft Access 


JnixJ 

H X ite e H ◄ ► H 



Figure 36. “Add new vehicles to a unit” Form 



Figure 37. “Add new weapons to a unit” Form 
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2 , 


OUTPUT FORMS 


y !?" "ai Y. li 5i Jt % ca M < ► H JOl - -.peaq^stonferhelp . 



Figure 38. “Modify unit” Form 



Figure 39. “More details” Form Based on # of Occupied Jobs (Actual Manpower Cost) 
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H zi aA ^ G ‘ * ► ►■ 'W iQl E Type a^sbon for help - 



Figure 40. “More details” Form Based on # of Jobs (Budgeted Manpower Cost) 


mssss^ ^xj 

H !?' 1 aJ C h ► M a i 



Figure 41. “Modify job” Form 
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Q Microsoft Access 


^Xj 

H 'a Ai i%i e M < ► M ii E 



Figure 42. “Modify rank with salary” Form 


Q Microsoft Access 




H '§ ™ zi a1 ^ ^ ^ H jfl| El "^ype a question for help 



Figure 43. “Modify vehieles” Form 
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Q Microsoft Access 


H 5?- 'll Y_ j{, % e o M < ► H IjOl ■ -vpeaquestonforhelp . 



Figure 44. “Modify weapon” Form 


y ".?' '01 Y. •?< ?i X % e. H < ► M ■* H 1 -.peawestonferhdp . 



Figure 45. “Modify jobs in a unit” Form 
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Figure 46. “Modify vehicles in a unit” Form 



Figure 47. “Modify weapons in a unh” Form 
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APPENDIX G: PROTOTYPE OF QUERIES 


1. SINGLE-TABLE QUERIES 



Figure 48. “Units” Query 


y e, M < ► M i0| B -^peaquestKjnfbrhdp . 



Figure 49. “Jobs” Query 
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Q Microsoft Access 


H ll Y. '?< li II -- l< < K M m 


■ inl x| 


/pe a question for help 















S Query salaries 









X 




Rank 

Rank Level 

Basic Salary' 

Yearly 

Increment 

Rate% 

Trans. 

allowance 

Social 

allowance 

Living 
allowance Y 

Clothing 
allowance Y 

— 



► 

1 i 1 

Officer 1 

se.Joo.M 1 

1 5.00 1 

5100.00 

1 5100.00 |j 

5500.00 

5350.00 1 





1 ^'<5 1 

Officer | 

56,000.00 1 

1 5tl0 1 

5100.00 

1 5100.00 |j 

S500.00 

5350.00 1 





1 ltg 1 

Officer | 

55,500.00 1 

1 5.00 1 

5100.00 

1 5100.00 || 

5500.00 

5350.00 1 





! BG 1 

Officer | 

55,000.00 1 

1 5.00 1 

5100.00 

1 5100.00 || 

5500.00 

5350.00 1 





1 COL 1 

Officer | 

54,500.00 1 

1 5.00 1 

5100.00 

1 5100.00 II 

5500.00 

5350.00 1 





1 ltc 1 

Officer 1 

54.000.00 1 

1 5.00 1 

5100.00 

1 5100.00 II 

5500.00 

5350.00 1 





1 1 

Officer 1 

53,500.00 1 

1 5.00 1 

5100.00 

1 5100.00 11 

5500.00 

5350.00 1 





1 CAPT 1 

Officer 1 

53,000.00 1 

1 5.00 1 

5100.00 

1 5100.00 |j 

5500.00 

5350.00 1 





1 c. i: 

Officer 1 

52,500.00 1 

1 1 

5100.00 1 

1 5100.00 || 

5500.00 

5350.00 1 





1 -«<“-< 1; 

Officer 1 

52,000.00 1 

1 5.00 1, 

5100.00 1 

1 5100.00 11 

S500.00 

5350.00 1 





1 War |i 

Enlisted 1 

51,500.00 1 

1 5.00 1 

5100.00 1 

F liMiM "11 

5500.00 

5250.00 1 





] 2ndWar 

Enlisted | 

51,300.00 1 

1 5.00 1 

5100.00 1 

1 5100.00 |1 

5500.00 

5250.00 1 





Return to Queries 







d 














Record: H | < 11 


1 ► 1 ►! 

l>*l of 18 










Figure 50. “Salaries” Query 



Figure 51. “Vehicles” Query 
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m 


Microsoft Access 


H 5?- ll li Ite e, H < ► H |U| II 


I Type a question for hdp 


^ Query weapons 


\Veaponn*pe Initial cosc’weapon Manufacturing Production rear Maintenance Maint. Cost 

coantn- r>te <M) for this Ye.r 


Description ^ 


► 

ca:inon| 

r 

sf:oo,000.00 

nr 

FR 

nr 

:ooo 

nr 

5 

l| $189,150.00 






|] 155 Howitzer 


SFOOO,000.00 

nr 

USA 

nr 

1999 

nr 

6 

J| $262,478.96 i 

ARTILLERY \^•EAPOX 


' 1 
1 



j 60 Howitzer 

ir 

$50,000.00 

nr 

USA 

nr 

2000 

nr 

5 

|j $4,728.75 1 






I 66nun ROCKETS 

ir 

$10,000.00 

nr 

USA 

nr 

1999 

nr 

6 

II $2,62477 j 

axti-tant: \^'eapon 


. , j 

SYSTEM 


Return to Queries 


Record: l< I < ll 1 » I >1 l>*l of 20 


d 


Figure 52. “Weapons” Query 


Q Microsoft Access 


H '§1 zi li Jii 6i ^ ► ►! i;"^ U E Type a question for help - 



Figure 53. “Manpower” Query 
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Figure 54. “Units_vehicles” Query 



Figure 55. “Units_weapons” Query 
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2, 


MULTIPLE-TABLE QUERIES 


Q Microsoft Access 


-lalxl 


H 'll zi Ai 6 “ < ► ►' il n lypeaquesbooforhelp 



Figure 56. “Unit manpower” Query 


Q Microsoft Access 


H 5?" '1 Y. zl ii (B * > M ;;4 U H ^ a ^sOon for hdp 



Figure 57. “Unit vehicles” Query 
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O Microsoft Access 


.jnjxj 


H 'll Y. ■?< Si 5i 


< » M ii m 

' . pe a quest)on for help » 

1 M Query unit weapons_Multlquery 





ManjKiwer list|7i5 

Annual saUries|S6.5S3,200.00 { 

I’nii typejinfantn- 

d 

Officer Ustj33 

\'eliicleslonlc<is<|S20.82(S.000.00 | 

Unit size|BattaHon 

_J 

Enlisted lUi|«82 

Weapons total costjS3, 486, 000.00 | 


D Proposedl'nit 
BaseOccupiedJobs 





Unit ID 

We^XKi 

Initial cost/weapon 

Weapons quantity 

Description 

► 

101 

60 Howitzer 

$30,000 00 

9 


101 

81 Howitzer 

S60 000 00 

6 



101 

9mm Auto-Gun 

$5,000,00 

14 



101 

9mm PISTOL 

$500 00 

2 PERSONAL WEAPON 


101 

GPMG 

$10,000.00 

54 GENERAL PURPOSE MACHINE GUN (7 66MM1 


101 

M16 (5 56mm) 

SI.000.00 

soil PERSONAL WEAPON 


101 

Med-Range Auto 

S5. 000.00 

39 


101 

MK-19 

$20,000 00 

13 



101 

Sniper Auto-Gun 

S8.000.00 

2 



101 

Sniper Rifle 7 62 

S5. 000.00 

5 


101 

Tow 

$100.000 00 

12 


jiiiiE 


1 ► I of 11 


Return to Queries 


1 ► I >1 U*! of 6 


Figure 58. “Unit weapons” Query 


Q Microsoft Access 




y "y- Y It .1= 111 ‘ ^ H < ► m ^ u 


"ype a question for help 



Figure 59. “Job in units” Query 
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Figure 60. “Vehicles in unit” Query 


S Microsoft Access 


Exit 3 WindowHtde 3 WinowUnhide "«pe a quesbon for help 



Figure 61. “Weapons in unit” Query 
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CREATING AND VIEWING USER’S QUERIES 


Remember! 


Note: You can build your o-ffn query based on all Tables and Select Queries available in the Database by clicking the above 
"Great my query" button. If you want to view your own Query(s) do the following: 

* Click on the "View my query^sf button 

* Click OK to View aeated queries 

“ Duble didc on the Query you want to open 

“ Or select the Query you wish to redesign then dick on Design button 
“ When done, minimize the Database Window OR dick on "Hide Window" button in the tool bar 



Figure 62. “Reminder instructions” Window 



Figure 63. “New query” Window 



lables/Queries 


ts by Unit type and sitel 



Table: Llnits_Weapons 
Table: Vehicles 

* 

^elected Fields: 

Query: Ana'yS!S_Comoafe two units 

Query: Analysis_Compare two units byy 
Query: Analysis_Compare two units by v 
Query: Analysis_Compare two units by 
Query: Analysis_Llryt based manpower q 
Query; Analysis L'nit based vehicles cue 





Cancel 



Figure 64. “Simple query wizard” Window 


□ 


WHch fields do you want m your query? 

You can choose from more than one table or query. 


lables/Queries 
|Que-v: Ara ,■». 

Available Fields: 


;Compare all uni »I 



gnish I 


Figure 65. “Selecting the new query fields” Window 
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I Simple Query Wizard 



What t!tie do you want for your query? 



That's all the informaton the wizard needs to create your 
query. 

Do you want to open the query or modify the query's design? 

^ Open the query to view informaton. 

Modify the query design . 

I” Display Help on working with the query? 


Cancel 


< Back 


Finish 


Figure 66. “Naming the new query” Window 



Figure 67. “Opening the new query” Window 



Figure 68. “Viewing the new query” Window 
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APPENDIX H: PROTOTYPE OF REPORTS 


1. SAMPLE REPORTS 



Figure 69. “Unit manpower comparison” Report 
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Q Microsoft Access 


Page Setup... Q 


^xj 

Type a quesfion for help » 


M’S ^ (M) 


100% 


Close Setup Jff » B a* 13 


List of weapons in unit 


^Xj 

—3 


List of weapons in Unit 101 


l'nitt\pe 

Unit size 

Weapon type 

Initial 

cost'weapon 

Weapon 

s 

Description 

Infantry 

Battalion 

Tow 

5100.000.00 

12 




Sniper Rifle 7.62mfn 

SS.MO.OO 

C 




Sniper iptoKSun 

S8.000.00 

2 




MK-19 

S20,W0.00 

13 




Med-Hange Auto Gun 

SS.000.00 

39 




M16 i:5.56mm) 

S1.000.00 

609 

PERSONAL vVEAPOM 



GPM G 

S10,000.00 

54 

GENERALPURPOSE MACHINE 






GUN 17.66MM) 



9mm PISTOL 

SEOO.OO 

2 

PERSONAL WEAPON 



9mm Ajto-Gun 

ss.ooo.oo 

U 




81 Hovitzer 

550.000.00 

6 




60 Hovitzer 

530.000.00 

9 



Jf'eapons total cost: $3,486,000.00 
Page: K I < 11 T » I >i | jJ 




LT 


Ready 




Figure 70. “List of weapons in unit” Report 


2 . 


CREATING AND VIEWING USER’S REPORTS 


Remembeii 


Note: You can build your own report based on all Tables and Select Queries available in the Database by clicking the above 
"Great my report” button. If you want to view your own Report(s1 do the following: 

^ Click on the "View my report(s)" button 
“ Click OK to view aeated reports 

* Duble dick on the Report you want to open 

“ Or select the Report you wish to redesign then dick on Design button 

* When done, minimize the Database Window OR dick on "Hide Window" button In the tool bar 



Figure 71. “Reminder instruetions” Window 
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New Report 



View 


Report Wizard 
AutoReport: Columnar 
AutoReport: Tabular 
Chart Wizard 
Label Wizard 


Choose the table or query where 
the object's data comes from: 


Analysls_Compare all units b’ 
Analysis_Compare Two units 
Analysis_Compare two units 
Analysls_Compare two units 


I 


Figure 72. “New report” Window 



Figure 73. “Starting to design the new report” Window 



Figure 74. 


“New report in design phase” Window 
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Figure 75. “Opening the new report” Window 


Q Microsoft Access - [XX] 


ia RIe Edit Vie-A Window 


!M-#|P0Elli “O'”' 


Help 

Close 



^x] 

- _ i5 X 

-3 


Report 1: Existing units statistics 

VnitlD Annual itdojy Tramponadon Social Lh’ing Clothmg I'ehicUs total yehiclemaint Weapons total Weapon maint 

aUo*i-ance allegiance allon ance/Y aUe>i ance/Y cost cost this Y cost cost this Y 



101 S6.866.400.00 

S75.600.00 

S398.160.00 

S367.500.00 

S180.350.00 

S20.326.000.00 

S12.S01.106.01 

S3.-i36.000.00 

S769.145.63 



102 SIO.584,000.00 

S180.000.00 

5636,000.00 

S5 5 0.000.00 

S266.500.00 

528.600,000.00 

55.154.178.54 

S3.921.500.00 

S1.029.303.44 



103 S8.122.800.00 

S70.800.00 

S507.120.00 

5434,000.00 

S235.500.00 

526.072.000.00 

SI 5.235.972.67 

S14.365.500.00 

S2.505.049.63 












1 Psoe: t4 1 4 II 1 > 1 >1 1 <1 





1 


Ready 











Figure 76. “Viewing the new report” Window 
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APPENDIX I: PROTOTYPE OF ANALYSIS FORMS 



Figure 77. “Compare two units” Form 



Figure 78. “Compare two units by jobs” Form 
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Figure 79. “Compare two units by vehieles” Form 



Figure 80. “Compare two units by weapons” Form 



Figure 81. “Querying the unit type” Window 



Figure 82. “Querying the unit size” Window 
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Q Microsoft Access 


_ ^ x] 

y zi Ai jfe Ite >■' H i ► H ^ I] 'ype a quesfion for help - 



Figure 83. “Compare units by type and size” Query 



Figure 84. “Copying any unit in the database as a proposed one” Window 
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H ".?' 'll ^- '?< zi Ji X 1^ 6 ■' l< * * H iU -.pea<^st(xiforhelp - 



Figure 85. “Viewing and apply “What if’ method on all proposed units” Form 


1 IQ Microsoft Access 

\ ^2<il 

Exit 3 VVindo'A'Hide 2 W'inowUnhide ' 

Type a question f&. nelp 


Optimization models 


iB _ 



s_ 


'infantry Battalion' 


Armor Battalion.xls 


Return to Analysis 


Figure 86. “Optimization models” Switchboard 
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APPENDIX J: BRIEF USERS’ MANUAL 


1, PURPOSE 

This DSS helps the users (mainly the force structure planners) to establish the cost 
of creating and maintaining an operational military unit, which in turn will aid the 
decision-makers or planners in tracking and monitoring the manpower and staffing 
requirements, operational support requirements and the proposal or approval of a cost- 
effective organization. The DSS tool can also be used to perform additional functions 
such as monitoring and highlighting job vacancies and manpower shortfalls or surpluses 
in an organization, as well as comparing the costs of maintaining two or more units in an 
organization. 

2, GETTING STARTED 

The database program is stored in a filename, entitled “BDF DSS”. Install the 
program by copying the fide into your computer. Before you are allowed to access or use 
the database program, you must be an authorized user. You will need an authorized user 
id and password to access the program. Please see your department system administrator 
and request a user id and password if you do not have one and you are an authorized user. 
Once you enter the program with the authorized user id and password, a menu 
switchboard will appear and you will be ready to use the database program. 


3. USING THE SWITCHBOARD 

The switchboard shows a list of menus on which you can find the options to 
perform the necessary tasks as defined. There are four main menus, comprising Forms, 
Queries, Reports, and Analysis. Just click on the icon to access the submenu functions 
you need. The icon, “Return to Main menu”, appears in all submenus and allows the 
users to return to the main menu at any time during the program execution. Figure 87 
shows the main menu switchboard of the BDF DS tool. 
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Q Microsoft Access 




Exit 2 WindowHide 2 WinowUnhide T.-pe a question for help 



Figure 87. Main Menu Switehboard 


4. USING FORMS 

The forms are intended to allow the authorized user and system administrator to 
ADD new and MODIFY existing data in the database. Figure 88 depicts the “Forms” 
switchboard. In the ADD function, you can choose to insert new types of unit, weapons, 
jobs or vehicles. You can also choose to insert a particular job or weapon or vehicle into a 
unit. But for the latter, you must first create the new job, weapon or vehicle in the 
database before you can insert the new job or weapon or vehicle into a unit. 
Additionally, the ADD forms are supported with tool bar icons (located at the upper part 
of the window) for record editing, navigation, and sorting purposes. 

In the MODIFY function, you can choose to update or delete existing data records 
or fields of each data type. Similarly, MODIFY forms are supported with tool bar icons 
that have two extra functions, namely, record filtration and record representation via 
charts or pivot tables. All ADD forms are created using the data entry form format. The 
lists of data which can be added and modified are given as follows: 

• Unit 

• Job 

• Rank with Salary Info. 
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• Vehicle 

• Weapon 

• Jobs to a Unit 

• Vehicles to a Unit 

• Weapons to a Unit 


Q Microsoft Access 


Exit 2 WindowHide 2 WinowUnhide I Type a quesbon for help 



Figure 88. Forms Switchboard 


5. USING QUERIES 

From time to time, users may want to query the data to answer questions or 
identify problems or particular situations. Two main classes of queries were thus created 
in this design. The users can choose to make either single queries or multiple queries as 
shown in Figure 89. 
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Figure 89. Queries Switchboard 


a. Single Queries 

These are mainly standard queries, which are created to provide responsive data 
to the users and to facilitate the users’ query requirements. In a single query, the query is 
directed only at a single table. For example, the users can query the list of units or the list 
of jobs or the list of weapons, etc in the database. Queries may be directed at the 
following; 

• Units 

• Jobs 

• Salaries 

• Vehicles 

• Weapons 

• Manpower 

• Vehicles in Units 

• Weapons in Units 
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b. Multiple Queries 

For these queries, users are allowed to direet queries at two or more tables. For 
example, the users ean make use of multiple queries to compare the operating costs of 
establishing two units in terms of manpower, weapons, and vehicles. The lists of such 
queries are given as follows: 

• Unit manpower 

• Unit vehicles 

• Unit weapons 

• Job in units 

• Vehicle in units 

• Weapon in units 

c. Additional feature 

Moreover, the users are also allowed to conduct further searches on their own if 
the standard queries above do not meet their requirements. In other words, the users can 
create their own query based on all available tables and previously created queries in the 
database. The steps for executing this function are documented in the Query main menu 
form via the “Create my query” and “View my query(s)” command buttons. 


6. USING REPORTS 

A report is a formatted display of database data. There are in total 6 types of 
reports that are currently included in this database system as shown in Figure 90 below. 
However, it is possible for the users to define many different types of reports based on the 
tables and queries in the database. Users can create and view such reports by following 
steps similar to those described in the query section above. For the given reports, the 
users will need to select the data type to display. For example, when comparing the 
manpower between two units, the users will need to insert the unit id to compare the data. 
The different types of reports are as follows: 

• List of jobs in Unit 

• List of vehicles in Unit 

• List of weapons in Unit 

• Make manpower comparison between 2 units 

• Make vehicles comparison between 2 units 

• Make weapons comparison between 2 units 
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Figure 90. Reports Switchboard 


7. USING ANALYSIS 

The force structure planners will spend most of their time using the functions in 
the Analysis menu shown in Figure 91 below. Initially, the users can utilize the different 
types of comparisons available in this menu to see the units’ differences. Secondly, users 
can simulate any unit structure in the database by copying it to a different unit id. The 
copied unit structure can then be manipulated and analyzed to generate other scenarios 
needed for the study. Thirdly, the users can utilize the human resource optimization 
models linked to the program to support their assumptions and solutions when proposing 
a unit structure. Also, users can view the proposed unit structures and apply the “what if’ 
technique to the units’ resources and match them with the best solutions found in the 
optimization models. Finally, the users can see the unit statistics based on either the 
number of jobs that refer to the unit budget cost or the number of occupied jobs that refer 
to the unit actual cost. 
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Figure 91. Analysis Switchboard 


8. SECURITY 

There are two main classes of users; namely the force structure planners and the 
system administrators. The main responsibility of the system administrator is to protect 
the data created in the database and ensure that only authorized users are allowed to 
access and use the data. The system administrator accomplishes the control through the 
granting of the appropriate access rights to the users. All authorized users will be given a 
user’s ID and a password in order to access the database system. Additionally, all 
developed tables, forms, queries, reports, and macros are protected against deletion and 
alteration by regular users. 
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